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1.  Executive  Summary 

The  National  Institute  of  Standards  and  Technology  (NIST)  Robot  Systems  Division  is 
participating  in  a Federal  Highway  Administration  (FHWA)  program  that  is  to  lead  to  the 
recommendation  of  standards  in  Vehicle- to-Roadside  Communications  (VRC)  equipment 
used  in  commercial  vehicle  operations  (CVO).  There  is  substantial  motivation  to  develop 
these  standards,  both  on  the  part  of  the  government  and  the  CVO  community.  A 
standardized  VRC  system  will  allow  states  to  check  credentials,  weight,  and  safety 
parameters  while  commercial  vehicles  travel  at  highway  speeds  of  up  to  160  km/h  This 
wiU  improve  the  current  simation  in  which  substantial  time  and  productivity  is  lost  while 
commercial  vehicles  stop  and  wait  for  inspections.  More  sophisticated  systems  may 
employ  weigh-in-motion  equipment,  on- vehicle  sensors  to  determine  brake  temperature  and 
other  parameters  in  real-time,  and  other  subsystems  (navigation,  etc.)  capable  of 
generating  relevant  data.  This  communications  link  wiU  serve  an  important  role  in  passing 
data  between  various  on-board  intelligent  control  system  computers  and  the  roadside 
systems. 

Numerous  incompatible  VRC  designs  and  protocols  exist,  or  are  being  developed.  The 
deployment  of  incompatible  systems  wiU  not  result  in  transparent  borders,  where  a truck 
can  pass,  for  example,  from  one  state  to  another  without  stopping.  A standard  is  to  be 
developed  or  chosen  that  will  meet  current  and  projected  requirements,  such  as  those  of  the 
Intelligent  Vehicle  Highway  System  (TVHS). 

This  is  an  intensive  program,  intended  to  yield  results  early  enough  to  reduce  the  current 
proliferation  of  incompatible  systems.  The  standards  of  interest  are  associated  with  the 
transponder  on  the  vehicle.  One  such  standard  will  specify  the  interface  between  the 
transponder  and  the  roadside  communications  equipment  (the  RF  interface).  The  other 
standard  of  interest  will  specify  the  interface  between  the  transponder  and  an  On-Board 
Computer  (OBC). 

While  this  program  focuses  on  the  transponder  technology  and  interfaces,  development  of 
these  standards  requires  an  understanding  of  the  impact  which  they  will  have  on  roadside 
communication  components  and  infrastructure  as  well  as  an  understanding  of  the 
transactions  to  be  conducted  through  the  VRC  system.  The  specified  interfaces  must  be 
capable  of  supporting  the  present  needs  of  CVOs  in  all  states,  and  anticipated  future  uses. 
To  understand  the  scope  of  the  problem,  consider  that  each  state  currently  maintains  data 
bases  on  operating  authority,  vehicle  registration,  motor  fuel  taxes,  oversize  and 
overweight  permits  and  motor  carrier  safety  inspections.  Typically,  these  are  independent 
data  bases  maintained  by  separate  state  agencies  that  include  public  service  commissions, 
departments  of  motor  vehicles,  departments  of  revenue,  departments  of  transportation  and 
state  police  or  highway  patrols.  Information  specific  to  the  driver  is  also  important.  The 
states  vary  widely  in  the  current  level  of  automation,  if  any,  of  these  data  bases.  As  a 
result,  many  important  issues  must  be  considered.  These  include  the  issues  of  data 
distribution  (How  much  information  is  on-board  the  vehicle?  How  much  does  a driver 
carry  on  a smart  card?),  performance  (How  frequently  must  the  data  be  updated?  What 
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transactions  need  to  occur  in  real-time  as  the  vehicle  passes  a VRC  reader  at  highway 
speed?),  and  security  (prevention  of  tampering  with  the  information). 

MST  interacted  with  various  CVO  user  bodies,  VRC  equipment  manufacturers,  state 
Department  of  Transportations  (DOTs),  IVHS  planners,  Lawrence  Livermore  National 
Laboratory  (LLNL),  and  other  government  agencies  to  deterrmne  the  current  and  projected 
VRC  requirements  for  CVO  and  the  current  and  expected  near-term  capabilities  of 
numerous  systems  and  protocols.  Fifteen  systems  and  six  protocols  were  examined  in  this 
study,  which  began  in  April  1993  and  concluded  in  December  1993. 

As  a result  of  this  effort , we  have  been  able  to: 

1 . Identify  the  requirements  of  a system  that  would  support  CVO. 

2.  Identify  the  current  and  expected  near-term  capabilities  of  applicable  VRC 
technology  and  standards. 

3.  Determine  that  the  present  and  expected  near-term  CVO  requirements  can  be 
met  by  existing  or  very  near-term  systems. 

4.  Determine  that  a standard  protocol  can  be  defined  that  is  based  largely  on 
existing  public  domain  protocol  specifications  which  will  have  the  capabilities 
required  for  CVO  functions. 

5 . Provide  specific  recommendations  for  protocol  and  technical  characteristics  to 
FHWA  for  inclusion  in  a CVO  VRC  standard. 
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2 . Introduction 

2.1  Background 

Under  the  sponsorship  of  the  Federal  Highway  Administration  (FHWA),  the  National 
Institute  of  Standards  and  Technology  (NIST)  and  Lawrence  Livermore  National 
Laboratory  (LLNL)  began  a program  in  April  1993  to  examine  Vehicle-to- Roadside 
Communications  (VRC)  systems  and  standards  in  an  effort  to  reduce  incompatibilities 
through  recommendations  for  interface  standards  for  Commercial  Vehicle  Operations 
(CVO).  A typical  VRC  system  employs  a roadside  communication  element,  an  on-vehicle 
transponder  or  tag,  possibly  an  interface  between  the  on-vehicle  transponder  and  the  on- 
vehicle  computer,  and  an  on- vehicle  operator  interface  that  may  contain  a display  or  smart 
card  type  device.  NIST's  Robot  Systems  Division  was  tasked  to  perform  a rapid 
determination  of  CVO  requirements,  examine  the  available  technologies  and  their  expected 
performance  and  capabilities,  and  present  recommendations  to  FHWA  for  standardization 
of  the  VRC  protocol  and  characteristics  of  the  transponder  to  On-Board  Computer  (OBC) 
interface. 

This  has  been  an  intensive  program,  intended  to  yield  results  early  enough  to  reduce  the 
current  proliferation  of  incompatible  systems.  The  standards  of  interest  are  associated  with 
the  transponder  on  the  vehicle.  One  such  standard  will  specify  the  interface  between  the 
transponder  and  the  roadside  communications  equipment  (the  RF  interface).  The  other 
standard  of  interest  specifies  the  interface  between  the  transponder  and  an  on-vehicle 
computer. 

While  this  program  focused  on  the  transponder  technology  and  interfaces,  development  of 
these  standards  requires  understanding  the  impact  on  the  roadside  communication 
components  and  infrastructure  as  weU  as  an  understanding  of  the  transactions  to  be 
conducted  through  the  VRC  system.  The  specified  interfaces  must  be  capable  of 
supporting  the  needs  of  CVOs  in  all  states,  and  anticipated  future  uses.  To  understand  the 
scope  of  the  problem,  consider  that  each  state  currentiy  maintains  data  bases  on  operating 
authority,  vehicle  registration,  motor  fuel  taxes,  oversize  and  overweight  permits  and  motor 
carrier  safety  inspections.  Typically,  these  are  independent  data  bases  maintained  by 
separate  state  agencies  that  include  public  service  commissions,  departments  of  motor 
vehicles,  departments  of  revenue,  departments  of  transportation  and  state  police  or  highway 
patrols.  Information  specific  to  the  driver  is  also  important.  The  states  vary  widely  in  the 
current  level  of  automation,  if  any,  of  these  data  bases.  As  a result,  many  important  issues 
must  be  considered.  These  include  the  issues  of  data  distribution  (How  much  information 
is  on-board  the  vehicle?  How  much  does  a driver  carry  on  a smart  card?),  performance 
(How  frequently  must  the  data  be  updated?  What  transactions  need  to  occur  in  real-time  as 
the  vehicle  passes  a VRC  reader  at  highway  speed?),  and  security  (prevention  of  tampering 
with  the  information). 


2.2  Description  of  Problem 

Numerous  incompatible  VRC  designs  and  protocols  exist,  or  are  being  developed.  The 
deployment  of  incompatible  systems  will  not  result  in  transparent  borders,  where  a truck 
can  pass,  for  example,  from  one  state  to  another  without  stopping.  A standard  is  to  be 
developed  or  chosen  that  will  meet  current  and  projected  requirements,  such  as  those  of  the 
Intelligent  Vehicle  Highway  System  (TVHS). 
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There  is  substantial  motivation  to  develop  these  standards,  both  on  the  part  of  the 
government  and  the  CVO  community.  A standardized  VRC  system  will  allow  states  to 
check  credentials,  weight,  and  safety  parameters,  while  commercial  vehicles  travel  at 
highway  speeds  of  up  to  160  km/h.  This  will  improve  the  current  situation  in  which 
substantial  time  and  productivity  is  lost  while  commercial  vehicles  stop  and  wait  for 
inspections.  More  sophisticated  systems  may  employ  weigh-in-motion  equipment,  on- 
vehicle  sensors  to  determine  brake  temperature  and  other  parameters  in  real-time,  and  other 
subsystems  (navigation,  etc.)  capable  of  generating  relevant  data.  This  communications 
link  will  serve  an  important  role  in  passing  data  between  various  on-board  intelligent 
control  system  computers  and  the  roadside. 


2.3  Previous  Related  Work 

Several  groups  have  been  meeting  to  address  the  VRC  incompatibility  issue.  An  ASTM 
group  has  been  working  to  develop  a standard  for  short  range,  two-way  VRC  equipment. 
This  group  consists  of  members  from  FHWA,  state  DOTs  and  vendor  representatives.  An 
Electronic  Toll  and  Traffic  Management  (ETTM)  User's  group,  which  consists  of  toll 
authority  representatives,  state  DOTs  and  members  from  FHWA,  has  also  met  to  specify 
ETTM  user  requirements  for  future  national  compatibility.  Lawrence  Livermore  National 
Labs,  working  with  the  California  Department  of  Transportation  (CALTRANS),  has  also 
developed  a VRC  standard  for  toll  collection  which  is,  at  the  present  time,  the  standard 
VRC  protocol  for  the  state  of  CaHfomia. 


2.4  Approach 

NIST  interacted  with  various  CVO  user  bodies,  VRC  equipment  manufacturers  and 
vendors,  state  DOTs,  IVHS  planners,  Lawrence  Livermore  National  Laboratory,  and  other 
government  agencies  to  determine  the  current  and  projected  VRC  requirements  for  CVO 
and  the  current  and  expected  near-term  capabilities  of  numerous  systems  and  protocols. 
Fifteen  systems  and  six  protocols  were  examined  in  this  study.  The  results  of  this  study 
are  reported  in  this  document. 

In  Section  3 we  document  the  necessary  technical  attributes  of  a VRC  system  that  are 
required  for  it  to  perform  specific  CVO  functions.  Further,  attributes  which  might  be 
needed  for  future  IVHS  functions  were  considered  in  an  effort  to  determine  the  future 
demands  on  a VRC  system.  Three  data  models  are  defined  that  essentially  form  three 
different  groupings  of  CVO  functions.  These  models  provide  a means  to  compare  system 
capabilities  to  three  possible,  and  increasingly  sophisticated,  implementation 
configurations.  The  models  represent  the  possible  evolution  of  CVO  VRC  systems  from 
the  present  into  the  future.  The  CVO  (and  future  IVHS)  user  services  that  were  determined 
were  then  documented  in  a matrix  which  indicates  the  technical  characteristics  or 
requirements  that  must  be  present  to  perform  each  service. 

In  Section  4 we  document  the  technologies  that  are  available  or  expected  to  be  available  in 
the  near  future  for  VRC  implementations.  First,  we  examine  a number  of  communications 
protocols  for  the  tag-to-reader  RF  interface  and  document  their  important  characteristics. 
The  most  important  parameters  of  each  protocol  are  summarized  in  a matrix.  Similarly,  the 
capabilities  of  currently  used  on-board  computer  interfaces  and  of  other  standard 
communication  interfaces  that  might  be  considered  for  use  as  an  on-board  computer 
interface  are  presented.  Numerous  VRC  systems  were  examined  in  order  to  obtain  an 
understanding  of  the  current  capabilities  of  VRC  for  CVO,  and  to  determine  what 
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capabilities  might  be  reasonably  expected  in  the  near  future.  The  characteristics  of  the 
examined  systems  are  documented. 

In  Section  5 we  evaluate  the  information  presented  in  Sections  3 and  4 and  provide 
conclusions  and  recommendations.  Section  6 includes  a reference  list  for  the  resources 
used  in  this  study  and  Section  7 contains  an  Appendix  of  supporting  information. 
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3.  Identification  of  Requirements 

Many  uses  of  tag  technology  have  been  implemented,  planned  or  considered.  Each 
potential  use  places  certain  requirements  on  the  VRC  system.  This  section  reviews  these 
services  or  functions,  and  presents  the  technical  requirements  that  would  likely  to  be 
needed  to  implement  each.  In  an  effort  to  gather  enough  information  to  guide  the  selection 
of  the  best  type  of  VRC  system,  three  types  of  information  have  been  considered.  First,  in 
order  to  best  estimate  the  needs  of  the  future  and  to  increase  the  potential  application  areas 
of  a standardized  CVO  VRC,  services  envisioned  under  the  IVHS  program  which  are  not 
CVO  services  have  been  examined.  Second,  several  sources  were  studied  to  determine 
CVO-  specific  services  and  their  requirements.  Finally,  a number  of  requirements  that  are 
not  related  to  specific  services,  and  are  known  in  advance  were  also  studied.  These  include 
characteristics  of  the  VRC  system  such  as  its  necessary  ruggedness,  weather  resistance, 
etc.  These  are  all  described,  but  only  those  that  might  differentiate  possible 
implementations  are  included  in  the  requirements  matrix  which  is  presented  later. 

3.1  Relevant  IVHS  Services 

Numerous  services  that  could  use  tag  technology  are  envisioned  under  IVHS  outside  of 
those  being  considered  for  CVO  operations.  The  Vehicle-to-Roadside  Communications 
subcommittee  of  ASTM  (El 7.51)  has  documented  many  of  these  as  part  of  its 
standardization  effort  [1].  This  section  briefly  describes  these  services.  It  is  useful  to  keep 
these  services  in  mind  in  the  selection  of  a VRC  solution  for  CVO.  An  ideal  VRC  solution 
would  support  these  services  as  well.  If  this  is  not  reasonable,  a VRC  solution  can  be 
selected  which  does  not  exclude  these  capabilities  simply  through  lack  of  consideration. 
Most  require  capabilities  that  are  quite  similar  to  those  needed  for  CVO  activities.  These 
services  all  require  a reader/tag  system  in  which  the  tagged  vehicle  passes  through  the 
operational  field  of  the  reader  and  data  is  exchanged.  Differences  lie  in  the  nature  of  the 
transactions  and  the  amount  of  data  to  be  exchanged.  Instances  where  significant 
differences  in  requirements  exist  are  pointed  out. 


3.1.1  Electronic  Toll  Collection  (ETC) 

Several  variations  on  ETC  systems  exist  or  have  been  described  [2,  3,  4,  5,  6,  7].  The 
most  common  is  a open  road  application  where  the  tag  sends  an  ID  to  the  roadside  reader. 
The  vehicle  is  instructed  to  proceed  via  signs  or  lights.  Transaction  processing  is  handled 
off-line.  This  requires  only  a read-only  tag  system.  Additional  vehicle  classification 
equipment  may  also  be  used.  Systems  intended  to  record  toll  road  entry  location 
information  (as  in  the  case  of  a closed  road  application)  or  value  information  (stored-value 
tags)  in  the  vehicle  tag  require  read-write  tag  technologies.  Current  tag  technologies 
support  ETC  with  a small  amount  of  data  (128  to  256  bit  tags). 
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3.1.2  Airport  Applications,  Commercial  Vehicle  Fee  Collection  (CVFC) 

These  systems  are  used  for  the  automated  collection  of  fees  from  commercial  vehicles  when 
they  enter  and  leave  airports  with  customers.  Examples  include  taxis,  limousines,  and 
hotel  and  rental  car  shuttles.  Various  accounting  methods  are  used  to  determine  cost,  with 
the  vehicle  owner  typically  being  billed  for  each  month's  charges.  The  information 
exchanged  includes:  transaction  information,  lane  information,  and  detection  of  a violation 
(based  on  time-of-day,  etc.).  Processing  is  performed  off-line  and  a read-only  tag  is 
sufficient.  Data  quantities  are  comparable  to  the  ETC  service. 


3.1.3  Airport  Applications,  Restricted- Access  Roadways  (RAR) 

RAR  systems  provide  access  control  for  restricted  roads  within  airports.  The  tag  simply 
provides  the  proper  authorization  to  allow  passage.  Vehicles  with  invalid  tags  or  no  tags 
will  not  be  allowed  to  pass.  Operation  in  multiple-tag  environments  may  be  required,  for 
example,  where  trains  of  containers  or  personnel  carry  the  tags.  Data  requirements  are 
minimal  and  read-only  capability  is  sufficient. 


3.1.4  Transit  and  Intermodal  Operations 

Numerous  applications  for  tag  technology  are  envisioned  for  transit  operations.  They 
include: 


Position  Location 

Vehicle  position  along  a route  can  be  monitored  in  terms  of  the  location  of  the  last  reader 
contacted  and  the  time  since  that  contact.  Location  resolution  is  determined  by  reader 
spacing.  Read-only  capability  is  sufficient  and  data  quantity  is  small,  consisting  of  a 
vehicle  identification. 


Schedule  Monitoring  and  Control 

A two-way  VRC  (read-write  tag  technology)  equipped  vehicle  could,  on  the  basis  of 
schedule  monitoring  information,  be  directed  to  adjust  its  behavior  through  by-passing 
stops,  or  waiting  at  stops  in  order  to  more  accurately  comply  with  the  schedule.  Only 
small  amounts  of  data  should  be  necessary  to  convey  these  schedule  adherence 
adjustments. 


Dynamic  Dispatching 

Dynamic  dispatching  activities  might  include  the  uploading  of  schedules,  and  routing  and 
assignment  data  through  the  VRC  system  to  a vehicle  on-board  computer.  This  service  is 
more  demanding  of  the  VRC  system  than  those  previously  described  in  two  ways.  First,  it 
entails  the  communication  of  what  are  probably  the  largest  data  records  among  the 
proposed  transit  uses  of  VRC,  and  second,  it  requires  the  existence  of  an  interface  between 
the  tag  and  an  on-board  computer.  The  route  data  (perhaps  on  the  order  of  hundreds  of 
bytes)  must  be  exchanged  during  a pass  by  the  reader,  which  dictates  the  required 
performance  of  the  VRC  system.  The  transfer  of  this  information  to  the  on-board  computer 
should  be  timely,  but  is  not  required  to  be  completed  at  the  reader  location.  Therefore,  the 
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transfer  rate  of  this  interface  can  be  considerably  slower.  Completion  within  a minute  or  so 
is  probably  sufficient  to  keep  pace  with  the  rate  of  information  update. 


Vehicle  Condition  Monitoring 

The  ability  to  obtain  vehicle  operational  and  maintenance  information  on-route  and  at 
terminals  is  envisioned  through  the  use  of  VRC  technology.  An  on-board  computer  would 
likely  collect  the  information  and  provide  it  to  the  tag  through  an  interface.  Provisions  for 
engine  and  vehicle  diagnostics,  fuel  and  fluid  levels,  odometer  reading  and  other 
information  has  been  suggested.  Clearly,  the  set  of  potentially  useful  information  is  nearly 
endless.  However,  the  amount  of  critical  information  which  is  needed  from  the  vehicle,  at 
operating  speed,  is  probably  a small  subset.  Other  more  detailed  information  could  be 
available  to  systems  at  the  terminal,  avoiding  the  exchange  of  these  longer  records  at 
highway  speed. 


Priority  treatment  at  intersections,  HOV  lanes 

A transit  vehicle  can  make  its  presence  known  at  access  points  along  HOV  lanes  or  at 
intersections  capable  of  providing  priority  treatment  through  signaling.  A read-only 
capability  and  the  transmission  of  an  identification  would  be  sufficient  for  fiis  service. 


Automatic  Switching 

Train  contents,  route,  trip  and  special  information  can  be  used  by  rail  switching  stations. 
However,  information  beyond  an  ID  could  require  lengthy  data  records  that  must  be 
exchanged  at  train  speed. 


Automatic  next  stop  announcements 

Next  stop  announcements  can  be  performed  automatically  if  the  identity  of  the  present  stop 
is  known.  This  requires  two-way  communication  and  only  a small  amount  of  information. 

Toll  Collection  (see  ETC  above) 


Passenger  Count 

Schedule  adherence  and  dynamic  dispatching  decisions  can  be  improved  with  passenger 
count  information  from  the  vehicle.  This  requires  only  a small  amount  of  data  and 
probably  would  be  included  with  some  other  vehicle  status  message. 


Intermodal  Operations 

In  addition  to  providing  more  current  and  accurate  schedule  information,  hand-carried 
transponders  may  be  used  to  pay  transit  fares,  indicate  destinations  and  to  gain  access  to 
schedule  information  systems.  These  applications  seem  similar  to  toll  applications  in  that 
only  small  amounts  of  information  need  be  carried  and  the  hand-carried  unit  may  or  may 
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not  contain  "stored- value."  On  the  other  hand,  they  need  not  operate  at  highway  speeds, 
and  a premium  would  be  placed  on  small  size,  light  weight  and  low  power  consumption. 


Safety/Environmental  Monitoring 

Failures  of  emission-critical  vehicle  components  can  be  detected  by  on-board  diagnostic 
systems.  It  may  be  feasible  for  vehicles  with  such  a failure  to  report  their  identification  and 
fault  codes. 


Waste  Management 

Waste  management  involves  the  identification  of  the  carrier  and  any  hazardous  material  on 
the  vehicle  while  at  the  landfill  site.  This  is  a relatively  simple  application  requiring  only 
read-only  tag  technology,  with  the  hazardous  waste  information  adding  somewhat  to  the 
amount  of  data  required.  A reasonable  assumption  would  be  that  data  would  not  exceed  on 
the  order  of  100  bytes. 


Hazardous  Material  Transportation 

Equipping  hazardous  material  transporting  vehicles  and  hazardous  material  containers  with 
VRC  tags  will  enable  automatic  monitoring  for  regulatory  compliance,  fee  payment, 
electronic  bills  of  lading  and  other  related  services.  This  will  enhance  the  effectiveness  of 
enforcement  and  emergency  response  operations.  Because  of  the  importance  of  controlling 
and  monitoring  the  movement  of  hazardous  materials,  it  is  probably  reasonable  to  assume 
that  the  amount  of  information,  even  if  it  only  identifies  the  cargo  in  detail,  could  be  quite 
large,  perhaps  several  thousand  bytes.  It  is  not  clear  what  quantity  of  information  would 
neSi  to  be  exchanged  at  highway  speeds. 


Traveler  Information  (TI) 

Traveler  Information  is  a term  used  to  cover  a wide  variety  of  information  types  that  could 
be  sent  from  the  roadside  to  vehicle  to  assist  the  driver.  This  includes  information  on 
congestion,  alternate  routes,  navigation  and  vehicle  location.  This  type  of  information 
could  be  expected  to  exceed  several  hundred  bytes,  and  require  transmission  at  highway 
speeds.  More  accurate  traveler  information  can  be  provided  if  more  traffic  information  is 
available  to  traffic  management  centers.  Use  of  two-way  communication  would  allow 
traffic  management  centers  to  receive  information  from  the  vehicles. 


Commercial  Services  (CS) 

This  service  category  covers  another  wide  range  of  services  including  travel  service 
information,  restaurant  and  hotel  reservations,  automobile  service  center  information, 
personal  voice  mail  and  faxing,  and  entertainment  services.  While  many  services  could  be 
provided  that  require  only  small  amounts  of  data,  some  have  been  estimated  to  require 
lOOK  bytes  of  data.  Two-way  communication  would  also  be  required. 
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Traffic  Management  (TM) 

VRC  equipped  vehicles  may  be  used  as  probes  for  traffic  management  purposes.  A single 
vehicle,  tracked  through  a series  of  readers,  provides  information  necessary  to  infer  traffic 
flow  rate.  If  the  VRC  system  can  discriminate  between  lanes,  incident  detection  capability 
is  enhanced.  This  service  requires  only  a unique  vehicle  identifier  and  read-only 
technology. 


Emergency  Messaging  (EM) 

The  ability  to  generate  an  SOS  type  message  would  be  very  useful  in  a number  of 
emergency  situations.  The  message  itself  would  likely  be  short  and  not  place  a great 
demand  on  the  system.  The  practicality  of  this  approach  rests  on  how  likely  it  is  that  a 
short-range  transmission  from  a vehicle  would  be  picked  up  by  an  appropriate  receiver,  be 
it  another  vehicle  or  a reader.  In  any  event,  since  the  vehicle  must  initiate  the  message, 
two-way  communication  would  be  required. 

3.2  CVO  Requirements 

The  following  section  is  a list  of  Commercial  Vehicle  Operations  (CVO)  services  that 
would  be  supported  by  Vehicle  to  Roadway  Communications  (VRC)  and  a description  of 
each  service.  Several  sources  of  information  were  use  in  compiling  this  list  [8,  9,  10].  In 
addition,  documentation  describing  current  and  planned  testbed  programs,  such  as  the 
HELP  program  were  reviewed  for  their  contributions  to  the  requirements  definition  [11, 
12,  13].  We  have  provided  here  what  we  believe  to  be  reasonable  estimates  for  the 
amounts  of  data  required  for  each  service.  Specific  implementations  may  vary,  but  based 
on  a few  assumptions,  these  numbers  should  be  reasonable.  One  assumption  is  that  the 
information  that  is  typically  text,  such  as  Carrier  Name,  is  stored  as  text  (tiiat  is,  one  6-bit 
byte  per  character)  rather  than  as  some  more  compact  encoded  form.  Appendix  A provides 
the  details  of  how  each  estimated  field  size  was  determined. 


3.2.1  Automated  Safety  Verification 

The  Automated  Safety  Verification  service  is  aimed  at  significantly  enhancing  the  safety  of 
commercial  vehicle  operation.  This  service  can  be  divided  into  three  areas: 

Roadside  Access  to  Safety  Records 

This  function  will  develop  safety  record  systems  to  allow  enforcement  officers  to  access 
selected  safety  records  on  the  commercial  vehicle,  motor  carrier,  and  driver  from  the 
roadside.  The  safety  records  will  include:  1)  safety  fitness  and  perfoimance  of  the  motor 
carrier,  2)  vehicle- specific  safety  records  such  as  the  date  and  violations  since  the  last 
inspection,  and  3)  the  safety  record  of  the  driver.  This  information  would  provide  an 
inspector  with  additional  information  to  make  a decision  about  which  drivers  and  vehicles 
to  perform  a detailed  inspection  on  and  which  to  let  pass  an  inspection  facility. 

Data  required: 

• Carrier  Name  120  bits 

• Carrier  ID  Number  84  bits 

• License  plate  number  and  state  for  each  vehicle  unit  50  bits 
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• Driver  name  120  bits 

• Time  driver  came  on  duty  28  bits 

• Driver  ID  Number  (CDL  number  & state  of  license)  86  bits 

• Driver  Social  Security  Number  (to  access  NLETS)  32  bits 

Estimated  Message  Length:  520  bits 


Roadside  Safety  Records  and  Status  Verification 

This  function  will  use  advanced  technology  devices  to  quickly  and  accurately  check  the 
vehicle’s  and  driver’s  safety  condition.  This  includes  1)  data  entry  and  information  access; 
2)  automated  vehicle  inspection;  3)  driver  safety  status;  and  4)  covert  monitoring  of  Out  Of 
Service  vehicles  (OOS). 

Data  required: 


• Carrier  Name  120  bits 

• Carrier  ID  Number  84  bits 

• License  plate  number  and  state  for  each  vehicle  unit  50  bits 

• Driver  Name  120  bits 

• Time  driver  came  on  duty  28  bits 

• Driver  ID  Number  (CDL  number  & state  of  license)  86  bits 

• Driver  Social  Security  Number  (to  access  NLETS)  32  bits 

Estimated  Message  Length:  520  bits 


On-board  Safety  Monitoring 

This  function  would  enable  enforcement  officers,  motor  carrier  logistics,  safety,  dispatch 
personnel,  and  drivers  to  review  vehicle,  cargo,  and  operator  safety  status  while  the 
Commercial  Motor  Vehicles  (CMVs)  are  traveling  at  highway  speeds. 

Data  required: 


• Carrier  Name  120  bits 

• Carrier  ID  Number  84  bits 

• Whether  or  not  cargo  is  hazardous  materials  4 bits 

• Driver  ID  Number  (CDL  number  & state  of  license)  86  bits 

Estimated  Message  Length:  294  bits 


3.2.2  Cross-border 

The  concept  of  this  service  is  to  extend  the  technologies  for  preclearing  commercial  vehicles 
at  state  borders  to  North  American  border  crossings. 

Automating  the  international  border  crossing  process  will  require  the  involvement  and 
cooperation  of  safety  enforcement,  registration,  fuel  tax,  immigration  and  customs  agencies 
of  the  three  countries  as  well  as  locd  transportation  officials  from  the  various  states  and 
provinces. 
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The  service  as  envisioned  would  allow  automated  clearance  of  regular  cross-border 
commercial  vehicle  operations.  This  would  likely  involve  the  use  of  transponder-equipped 
trucks,  smart  cards  for  driver  identification  and  clearance,  electronic  data  interchange 
between  certified  shippers  or  customs  agents  or  an  electronic  bill  of  lading  on  the  vehicle; 
the  ability  to  check  carrier  safety  and  credential  records;  and  two-way  communications  to 
the  vehicle  signaling  the  driver  to  pass  the  checkpoint  or  to  come  in  for  further  inspection. 

Data  required: 


• Carrier  Name  120  bits 

• Carrier  ID  Number  84  bits 

• What  permits,  if  any,  the  vehicle  is  operating  under  16  bits 

• Whether  or  not  carrier  is  registered  in  a "base  state"  4 bits 

• Base  state  for  vehicle  registration  (IRP)  8 bits 

• Base  state  for  fuel  tax  reporting  (ITTA,  RFTA)  8 bits 

• License  plate  number  and  state  for  each  vehicle  unit  50  bits 

• Whether  or  not  cargo  is  hazardous  materials  4 bits 

• Driver  Name  120  bits 

• Time  driver  came  on  duty  28  bits 

• Driver  ID  Number  (CDL  number  & state  of  license)  86  bits 

• Driver  Social  Security  Number  (to  access  NLETS)  32  bits 

Estimated  Message  Length:  560  bits 


3.2.3  Electronic  Credentials 

By  the  year  2000  a nationwide  electronic  network  could  be  created  which  would  allow 
commercial  vehicles  to  travel  from  one  state  to  another  without  stopping  at  state  borders  to 
check  paperwork  for  fuel,  registration,  etc.  This  electronic  network  wiU  also  help  to  more 
efficiently  comply  vrith  state  tax  report  preparation,  auditing,  and  insurance  requirements. 

Electronic  Purchase  of  Credentials 

The  electronic  purchase  of  credentials  would  allow  a motor  carrier  to  apply  for,  pay  for, 
and  receive  a variety  of  credentials  electronically  from  a base  state.  Under  this  system  a 
trucking  company  could  apply  for  and  obtain  annual  state  credentials  (e.g.,  registration, 
fuel  tax,  trip,  oversize/  overweight,  hazardous  materials  etc.)  via  a computer  hook-up  to  the 
base  state  for  annual  credentials  and  to  individual  states  for  temporary  credentials  (e.g.  trip 
permits). 

This  is  an  off-line  function. 


Pre-Travel  Verification  of  Credentials 

Another  major  function  of  the  electronic  credentials  service  is  the  pre-travel  verification  of 
credentials.  This  function  would  provide  carriers  with  the  ability  to  verify  state  credentials/ 
requirements  prior  to  the  start  of  a trip.  The  carrier  could  then  access  individual  state 
licensing  databases  or  a bulletin  board  and  check  the  registration  and  permitting 
requirements  for  the  trip  or  the  status  of  a particular  vehicle  or  fleet  of  vehicles  prior  to 
dispatching.  With  this  capability,  a carrier  could  put  its  vehicles  on  the  road  and  be  assured 
that  they  would  be  legal  in  every  state  in  which  they  travel. 

This  is  an  off-line  function. 
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Nationwide  Motor  Carrier  Advisory  Bulletin 

Another  way  to  improve  the  credential  process  is  the  establishment  of  a nationwide  Motor 
Carrier  Advisory  Bulletin  Board.  Such  a bulletin  board  program  would  provide  carriers 
with  up-to-date  information  on  credential  and  permitting  requirements  in  each  state, 
including  information  on  whether  new  requirements  or  procedures  have  been  added  or 
existing  requirements  have  been  changed  or  eliminated. 

This  is  an  off-line  function. 


Mainline  Verification  of  Credentials 

Mainline  verification  of  credentials  requires  the  capability  to  identify  a vehicle  and  to  check 
its  credentials  without  having  to  stop  it.  This  can  be  done  by  either  transmitting  credential 
information  stored  in  an  on-board  computer  through  a transponder  mounted  on  the  truck  to 
a roadside  reader  for  evaluation  by  state  enforcement  officials  or  by  the  official  accessing  a 
database  elsewhere.  Readers  at  the  Port  Of  Entry  (POE)  for  a state  would  query  the  truck’s 
transponder  for  the  credential  information  and  determine  whether  the  carrier  is  in 
compliance  with  state  requirements.  If  the  carrier's  credentials  are  in  order,  the  driver 
would  be  signaled  not  to  stop.  Weight  information  from  weigh-in-motion  devices  could 
also  be  provided  to  the  POE  computer  at  the  same  time.  In  this  way,  the  computer  could 
compare  the  actual  weight  of  the  vehicle  against  the  registered  axle  weights  and  determine  if 
the  vehicle  is  traveling  legally. 

Data  required: 


• Carrier  Name  120  bits 

• Carrier  ID  Number  84  bits 

• What  permits,  if  any,  the  vehicle  is  operating  under  16  bits 

• Whether  or  not  carrier  is  registered  in  a "base  state"  4 bits 

• Base  state  for  vehicle  registration  (IRP)  8 bits 

• Base  state  for  fuel  tax  reporting  (IITA,  RFTA)  8 bits 

• License  plate  number  and  state  for  each  vehicle  unit  50  bits 

• Whether  or  not  cargo  is  hazardous  materials  4 bits 

• Driver  Name  120  bits 

• Time  driver  came  on  duty  28  bits 

• Driver  ID  Number  (CDL  number  & state  of  license)  86  bits 

• Driver  Social  Security  Number  (to  access  NLETS)  32  bits 

Estimated  Message  Length:  560  bits 


Electronic  Mileage  and  Fuel  Reporting 

Another  credential-related  service  that  would  benefit  both  states  and  the  motor  carrier 
industry  is  electronic  mileage  and  fuel  reporting.  Even  with  greater  standardization 
stemming  from  the  International  Registration  Plan  (IRP)  and  the  International  Fuel  Tax 
Agreement  (IFTA),  compliance  with  state  tax  reporting  and  record  keeping  requirements  is 
still  a major  effort  for  the  motor  carrier  industry.  For  registration  and  auditing  purposes,  a 
carrier  is  required  to  maintain  accurate  mileage  and  vehicle  information.  This  information  is 
captured  for  each  trip  on  an  Individual  Vehicle  Mileage  Record  (IVMR).  Information 
including  location,  date,  time,  mileage,  and  fuel  purchase  from  credit  or  smart  cards  could 
be  captured  at  state  crossings.  This  information  could  replace  the  manual  trip  log  which  is 
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typically  prepared  by  the  driver.  The  mileage  information  could  be  recorded  either/both  in 
an  on-board  computer  or  in  a remote  computer  location  managed  at  the  state  or  national 
level.  This  data  would  then  provide  the  means  to  automatically  create  tax  reports.  A fleet 
management  software  package  could  be  developed  to  calculate  tax  liabilities  and  prepare  tax 
reports.  Such  software  would  match  fuel  purchased  with  mileage  data  to  calculate  a 
earner's  tax  liability. 


Data  required: 

• Carrier  Name 

• Carrier  ID  Number 

• What  permits,  if  any,  the  vehicle  is  operating  under 

• Base  state  for  fuel  tax  reporting  (IFTA,  RFTA) 

• License  plate  number  and  state  for  each  vehicle  unit 

Estimated  Message  Length: 


120 

bits 

84 

bits 

16 

bits 

8 

bits 

50 

bits 

278 

bits 

3.2.4  Fleet  Management 

Fleet  management  has  primarily  been  a private  sector  activity.  However,  the  FHWA  is 
asking  whether  there  is  a need  for  public  or  DOT  involvement  to:  1)  facilitate  intermodal 
transfer,  2)  provide  real-time  traffic  information  to  dispatchers  and,  3)  provide  information 
to  carriers  on  the  benefits  of  improved  terminal  operations.  Also  this  service  would  support 
and  complement  public  sector  initiatives  in  safety  and  regulatory  enforcement  and  DOT 
initiatives  in  intermodal  transportation. 

This  service  would  provide  real-time  communications  between  commercial  vehicle  drivers, 
dispatchers,  and  intermodal  transportation  providers  which  would:  1)  reduce  delays  for 
drivers  and  2)  provide  commercial  drivers  and  dispatchers  with  real-time  routing 
information  in  response  to  congestion  or  incidents. 


Data  required: 

• Carrier  Name 

• Carrier  ID  Number 

• Whether  or  not  carrier  is  registered  in  a "base  state" 

• Base  state  for  vehicle  registration  (IRP) 

• License  plate  number  and  state  for  each  vehicle  unit 

Estimated  Message  Length: 


120 

bits 

84 

bits 

4 

bits 

8 

bits 

50 

bits 

266 

bits 

3.2.5  Hazardous  Materials 

This  service  is  aimed  at  enhancing  the  safety  of  shipments  of  hazardous  materials  by  truck. 
Hazardous  material  shipments  might  include  paint  being  transported  to  the  local  hardware 
store,  truckloads  of  gasoline  being  delivered  to  local  service  stations,  and  nuclear  weapons 
or  weapons-grade  plutonium  being  delivered  to  military  installations. 

This  service  focuses  on  being  able  to  determine  when  an  incident  involving  a truck  carrying 
hazardous  materials  occurs,  the  nature  and  location  of  the  incident,  and  the  materi^ 
involved  so  that  it  can  be  handled  properly.  While  these  functions  are  all  related,  an 
integrated  low-cost  system  that  can  be  used  by  local  responders  is  needed. 
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It  may  not  be  cost-effective  to  track  all  hazardous  material  shipments.  For  some  types  and 
amounts  of  hazardous  materials  it  may  only  be  important  to  locate  these  tmcks  when  they 
are  involved  in  a serious  accident  and  then  provide  specific  cargo  information  through 
electronic  placard  or  other  technology  on  the  vehicle. 

Data  required: 


• Carrier  Name  120  bits 

• Carrier  ID  Number  84  bits 

• What  permits,  if  any,  the  vehicle  is  operating  under  16  bits 

• Whether  or  not  cargo  is  hazardous  materials  4 bits 

• Driver  Name  120  bits 

• Time  driver  came  on  duty  28  bits 

• Driver  ID  Number  (CDL  number  & state  of  license)  86  bits 

Estimated  Message  Length:  458  bits 


3.2.6  Size  And  Weight  - Mainline  Weigh-In-Motion 

Trucks  which  are  legal  from  a size-and-weight  or  permit  standpoint  can  be  checked  at 
highway  speeds  and  Slowed  to  bypass  weigh  stations  and  ports  of  entry. 

The  four  main  parts  of  this  service  are: 

1.  Technologies  for  mainline  checking  of  axle  and  gross  vehicle  weights: 

♦ High-Speed  Weigh-In-Motion  (HSWIM) 

♦ Automatic  Vehicle  Classification  (AVC) 

♦ Automatic  Vehicle  Identification  (AVI) 

2.  Oversize/overweight  permit  data  bases  to  determine  whether  vehicles  exceeding  statutory 
weight  or  linear  dimension  limits  have  a permit  and  are  thus  operating  legally. 

3.  Model  instrumented  weigh  station  design. 

4.  Mobile  weight  enforcement.  In  addition,  this  service  will  research  and  test  alternatives  to 
screening  at  fixed  sites  including  high-speed  portable  WIM  and  on-board  weighing 
systems. 

Vehicle  weight  enforcement  is  an  activity  which  aU  states  have  historically  conducted  to 
protect  pavements  and  bridges  and  develop  a record  for  planning  construction  needs  in 
accordance  with  the  weights  that  are  moving  on  the  highway  system.  In  1974,  the 
Congress  made  active  weight  enforcement  a condition  to  be  met  in  order  for  a state  to  be 
eligible  to  receive  its  full  annual  apportionment  of  Federal- aid  highway  constmction  funds. 
All  states  actively  enforce  vehicle  weight  limits.  IVHS  technologies  can  significantly 
increase  the  efficiency  of  the  activity. 

Mainline  Screening  of  Weight 

Mainline  WIM  installation  and  attendant  technologies  (AVI,  AVC,  and  roadside/vehicle  2- 
way  communication)  are  considered  the  key  elements  to  providing  the  desired  service. 
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Oversize  and  Overweight  Permit  screening 

Vehicles  can  legally  exceed  statutory  weight  limits  through  the  use  of  an 
oversize/overweight  permit.  Therefore,  there  must  be  the  capability  to  determine  within  a 
few  seconds  the  existence  of  a permit  authorizing  the  movement.  Permit  conditions  and 
availability  vaiy  by  state,  however,  and  is  the  type  of  information  which  would  readily  lend 
itself  to  electronic  encoding  onto  a transponder  or  a credential  data  base  if  it  were  accessible 
in  real  time. 

Instrumented  Weigh  Station  Design 

As  existing  weigh  stations/ports-of-entry  are  rehabilitated  or  replaced,  redesign  should  be 
based  on  tiie  motor  carrier  services  that  are  expected  to  be  available  at  the  site  and  the 
anticipated  commercial  motor  vehicle  volumes.  A research  project  to  help  optimize  site 
usage  is  about  to  begin.  The  output  of  this  project  will  be  guidelines  for  maximizing 
operational  efficiency  both  for  new  locations  and  existing  locations  where  right-of-way 
availability  or  some  other  constraints  may  force  prioritization  of  services  that  can  be 
provided.  This  should  save  each  state  money  that  it  would  have  to  spend  for  weigh  station 
design  and  result  in  some  degree  of  nationwide  compatibility  for  carriers  that  desire  to  use 
the  available  services. 

Mobile  Weight  Enforcement 

Mobile  weight  enforcement  operations  are  a very  important  element  of  each  states  overall 
weight  enforcement  plan.  They  allow  states  to  more  efficiently  schedule  human  resources 
and  patrol  those  routes  used  to  evade  permanent  scales.  Portable  and  semi-portable 
HSWIM  will  be  more  important  in  the  future  as  the  major  highways  are  instrumented  and 
intentionally  illegal  vehicles  from  a weight  and/or  size  standpoint  attempt  to  evade 
detection. 

The  data  requirements  for  WIM  technology  can  be  summarized  below: 

Data  required: 


• Carrier  Name  120  bits 

• Carrier  ID  Number  84  bits 

• What  permits,  if  any,  the  vehicle  is  operating  under  16  bits 

• Whether  or  not  carrier  is  registered  in  a "base  state"  4 bits 

• Base  state  for  vehicle  registration  (IRP)  8 bits 

• Base  state  for  fuel  tax  reporting  (IKTA,  RFTA)  8 bits 

• License  plate  number  and  state  for  each  vehicle  unit  50  bits 

Estimated  Message  Length:  290  bits 


3.2.7  Carrier  Safety  Fitness 

This  service  would  access  the  carrier’s  “safety  rating”  and  would  allow  the  enforcement 
officials  a basis  to  make  a decision  about  which  drivers  and  vehicles  to  perform  a detailed 
inspection  on  and  which  to  let  pass  an  inspection  facility. 
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Data  required: 

• Carrier  Name 

• Carrier  ID  Number 

Estimated  Message  Length: 


120  bits 
84  bits 

204  bits 


3.2.8  Vehicle  Registration 

This  service  would  be  used  to  determine  what  base  state  the  carrier  is  registered  in,  if  the 
registration  is  current,  and  the  vehicle’s  registered  weight 


Data  required: 


• Carrier  Name 

• Carrier  ID  Number 

• Whether  or  not  carrier  is  registered  in  a "base  state" 

• Base  state  for  vehicle  registration  (IRP) 

• License  plate  number  and  state  for  each  vehicle  unit 

120  bits 

84  bits 

4 bits 

8 bits 

50  bits 

Estimated  Message  Length: 

266  bits 

3.2.9  Fuel  Tax 

This  service  would  be  used  to  determine  the  base  state  for  fuel  tax  reporting 
not  the  fuel  tax  payments  are  current. 

and  whether  or 

Data  required: 

• Carrier  Name 

• Carrier  ID  Number 

• WTiether  or  not  carrier  is  registered  in  a "base  state" 

• Base  state  for  fuel  tax  reporting  (IFTA,  RFTA) 

120  bits 

84  bits 

4 bits 

8 bits 

Estimated  Message  Length: 

216  bits 

3.2.10  Permits 

This  service  would  be  used  to  access  and  determine  the  existence  of  and  how  current  the 
necessary  permits  are  including  temporary  vehicle  registration  (trip  permit),  hazardous 
materials  (HM)  permit  based  on  cargo  carried,  oversize/overweight  permit,  etc. 

Data  required: 

• Carrier  Name 

• Carrier  ID  Number 

• What  permits,  if  any,  the  vehicle  is  operating  under 

• Whether  or  not  cargo  is  hazardous  materials 

120  bits 

84  bits 

16  bits 

4 bits 

Estimated  Message  Length: 

224  bits 

17 


VRC  Standard  Recommendations 


System  Requirements 


3.2.11  Accident  Rate 

With  the  mileage  from  the  registration  database  and  the  accidents  reported  to  the  Office  of 
Motor  Carriers  (OMC)  by  the  states,  the  accident  rate  could  be  calculated  to  determine 
whether  the  carrier  is  within  some  predefined  criteria  for  acceptability. 


Data  required: 

• Carrier  Name 

• Carrier  ID  Number 

• Base  state  for  vehicle  registration  (IRP) 

• License  plate  number  and  state  for  each  vehicle  unit 

• Driver  Name 

• Driver  ID  Number  (CDL  number  & state  of  license) 
Estimated  Message  Length: 


120 

bits 

84 

bits 

8 

bits 

50 

bits 

120 

bits 

86 

bits 

468 

bits 

3.2.12  Roadside  Inspections 

This  service  could  be  used  to  determine:  1)  When  the  vehicle  was  last  inspected  to  prevent 
the  vehicle  from  being  stopped  multiple  times  along  the  same  route  when  unnecessary,  2) 
Whether  or  not  vehicle  was  placed  out-of-service  during  last  inspection,  and  3)  License 
plate  number  on  individual  vehicle  units  (to  determine  whether  a particular  vehicle  unit  had 
defects  detected  during  a previous  inspection) 

Data  required: 


• Carrier  Name  120  bits 

• Carrier  ID  Number  84  bits 

• License  plate  number  and  state  for  each  vehicle  unit  50  bits 

Estimated  Message  Length:  254  bits 


3.2.13  Cargo  Data 

This  service  could  be  used  to  determine  which  types  of  hazardous  materials  and  amounts 
should  be  monitored  and  a unique  identification  for  each. 


Data  required: 

• Carrier  Name 

• Carrier  ID  Number 

• What  permits,  if  any,  the  vehicle  is  operating  under 

• Whether  or  not  cargo  is  hazardous  materials 

Estimated  Message  Length: 


120 

bits 

84 

bits 

16 

bits 

4 

bits 

224 

bits 
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3.2.14  Summary  - Required  Information  For  CVO  Services 

The  minimum  information  that  must  be  stored  on  the  vehicle  to  perform  the  described  CV O 
transactions  or  to  access  the  information  required  for  the  aforementioned  CVO  services 
from  a remote  database  is: 


• Carrier  Name 

• Interstate/Intrastate  Canier  ID  Number 

• What  permits,  if  any,  the  vehicle  is  operating  under 

• Whether  or  not  carrier  is  registered  in  a ’’base  state" 

• Base  state  for  vehicle  registration  (IRP) 

• Base  state  for  fuel  tax  reporting  (IFTA,  RFTA) 

• License  plate  number  and  state  for  each  vehicle  unit 

• Whether  or  not  cargo  is  hazardous  materials 

• Driver  Name 

• Time  driver  came  on  duty 

• Driver  ED  Number  (CDL  number  & state  of  license) 

• Driver  Social  Security  Number  (to  access  NLETS?) 


Estimated  Message  Length: 


120 

bits 

84 

bits 

16 

bits 

4 

bits 

8 

bits 

8 

bits 

50 

bits 

4 

bits 

120 

bits 

28 

bits 

86 

bits 

32 

bits 

560 

bits 

3.3  Analysis  of  CVO  Requirements 

The  estimate  presented  above,  of  somewhat  less  than  a thousand  bits  of  information  to 
support  CVO  transactions,  helps  to  clarify  the  scale  of  the  VRC  for  CVO  application. 
However,  this  estimate  alone  does  not  provide  enough  information  to  determine  the  data 
requirements  for  a VRC  tag.  It  does  not  consider  where  data  is  stored  or  how  the  data  is 
acquired.  Different  system  designs,  each  capable  of  supporting  the  described  CVO 
transactions,  can  have  very  different  requirements  for  the  amount  of  information  that  needs 
to  be  carried  on  the  tag.  In  order  to  provide  a structure  for  the  evaluation  of  the  various 
possible  implementation  technologies,  three  VRC  system  models  are  described  below. 
Each  system  will  be  evaluated  with  respect  to  its  ability  to  perform  within  each  of  these 
models. 


3.3.1  Model  1 

Model  1 represents  a system  requiring  a read-only  tag  carrying  a single  piece  of 
information,  an  identification  number.  This  model  can  employ  the  simplest  form  of  tag. 
Read/write  capability  is  not  required,  since  the  tag  stores  only  the  ID  number.  Roadside 
systems  are  required  to  obtain  any  desired  information  from  data  bases  using  the  ID 
number  as  the  only  key.  Although  many  transactions  can  be  performed  in  this  way,  this  is 
not  a likely  candidate  since  it  lacks  the  ability  to  provide  information  to  the  driver,  and 
because  it  demands  very  high  performance  in  the  retrieval  of  information  from  the  remote 
data  bases. 


3.3.2  Model  2 

Model  2 assumes  support  of  data  elements  on  the  tag,  in  addition  to  the  ID  number,  that 
permit  the  completion  of  a subset  of  the  CVO  transactions.  The  transactions  selected  can  be 
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completed  through  the  use  of  a read/write  tag  without  the  need  for  extraction  of  information 
from  a remote  data  base.  These  transactions  are  directly  aimed  at  main-line  screening  type 
activities.  The  data  elements  and  examples  of  the  transactions  are  described  below.  This 
model  is  intended  to  represent  a system  that  could  be  implemented  quickly  with  existing 
technology  and  still  provide  valuable  functionality.  Transactions  not  directly  supported 
through  the  use  of  tag  data  can  be  performed  through  the  remote  data  base  if  necessary, 
using  the  ID  number,  as  in  Model  1. 


Data  required  on  tag: 


♦ ID  32  bits 

♦ Weight  at  last  weighing  12  bits 

♦ Time  of  last  weigMng  28  bits 

• Safety  flags  4 bits 

• Time  of  last  safety  inspection  28  bits 

• Temporary  Permits  120  bits 

Estimated  Message  Length:  224  bits 


A read-write  tag  with  only  this  small  set  of  information  could  permit  the  following 
mainline  functions: 

Retrieval  of  weight  from  the  truck  for  purposes  of  calculation  of  fees  without  stopping 
or  re- weighing  the  truck. 

Determination  of  need  to  weigh,  based  on  age  of  weight  data  on  tag.  Permits  passing 
acceptable  vehicles  without  stopping  them. 

Examination  of  some  form  of  safety  indicator  or  flag  that  indicates  that  some  safety  item 
required  attention  at  last  inspection.  This  could  be  examined  to  see  if  correction  was 
made.  Time  of  last  inspection  could  be  used  to  determine  if  truck  should  be  stopped  or 
allowed  to  pass. 

Short-term  temporary  permits  could  be  issued  and  their  possession  indicated  on  the  tag 
for  easy  and  timely  verification.  Such  permits  might  provide  authorization  for  only  a 
few  days,  making  entering  and  tracking  them  through  a remote  data  base  impractical. 

Note  that  the  information  selected  for  inclusion  on  the  tag  in  this  model  is  the  type  of 
information  that  changes  frequently.  The  tag  is  a better  location  for  this  type  of  information 
since  it  can  be  changed  at  any  weigh  station.  This  permits  the  information  to  be  more 
timely  and  accurate  than  if  it  was  maintained  in  some  remote  central  data  base.  Employing 
this  model  places  no  additional  performance  demands  on  the  remote  data  bases. 

For  these  reasons,  a system  following  this  type  of  data  distribution  model,  may  be  a 
sensible  first  step  toward  CVOA^C  improvements. 

An  additional  class  of  frequently  changing,  or  perishable,  information  might  be  included  as 
well  under  Model  2 if  a smart  card  type  user  interface  is  available.  This  class  would 
contain  various  driver  specific  information,  which  would  need  to  be  changed  each  time  a 
driver  operated  a different  vehicle.  It  could  include  the  following: 

• Driver  Name  120  bits 

• Time  driver  came  on  duty  28  bits 

• Driver  ID  Number  (CDL  number  & state  of  license)  84  bits 
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• Driver  Social  Security  Number  (to  access  NLETS?) 
Estimated  Additional  Message  Length: 


264  bits 


32  bits 


3.3.3  Model  3 

Model  3 represents  the  most  far  reaching  of  the  models  presented.  It  represents  a system  in 
which  aU  of  the  CVO  transactions  described  are  intended  to  be  supported  by  the  tag,  with 
an  absolute  minimum  of  reliance  on  any  remote  data  bases.  While  the  exact  nature  of  such 
a VRC  system  is  not  yet  defined,  it  clearly  would  require  the  most  sophisticated  tag 
solution  of  the  three  models.  Such  a system  would  require  greater  on-tag  memory,  and  be 
flexible  enough  to  handle  all  possible  CVO  transactions,  as  well  as  support  toll  activities 
and  the  various  functions  envisioned  under  IVHS.  Support  of  these  advanced  functions 
would  almost  certainly  require  a user  interface  such  as  a smart  card  as  well  as  read/write 
capability.  The  data  requirements  to  support  CVO  alone  would  consist  of  all  of  the  data 
elements  described  under  CVO  Requirements  as  well  as  those  used  for  the  handling  of 
frequently  updated  information  described  for  a Model  2 type  system.  Together  they  are  the 
following: 


Required  Information  For  CVO  Services 

The  minimum  information  that  must  be  stored  on  the  vehicle  to  perform  the  described  CVO 
transactions  or  to  access  the  information  required  for  CVO  services  from  a remote  database 


is: 


Infrequently  changed  data: 


• ID 

• Carrier  Name 

• Interstate/Intrastate  Carrier  ID  Number 

• What  permits,  if  any,  the  vehicle  is  operating  under 

• Whether  or  not  carrier  is  registered  in  a "base  state" 

• Base  state  for  vehicle  registration  (IRP) 

• Base  state  for  fuel  tax  reporting  (lEl  A,  RFTA) 

• License  plate  number  and  state  for  each  vehicle  unit 

• Whether  or  not  cargo  is  hazardous  materials 


32  bits 
120  bits 
86  bits 
16  bits 
4 bits 
8 bits 
8 bits 
50  bits 
4 bits 


Frequently  changed  data: 


• Weight  at  last  weighing 

• Time  of  last  weighing 

• Safety  flags 

• Time  of  last  safety  inspection 

• Temporary  Permits 

• Driver  Name 

• Time  driver  came  on  duty 

• Driver  ID  Number  (CDL  number  & state  of  license) 

• Driver  Social  Security  Number  (to  access  NLETS?) 


12  bits 
28  bits 
4 bits 
28  bits 
120  bits 
120  bits 
28  bits 
86  bits 
32  bits 


Estimated  Message  Length: 


786  bits 
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Model  3 is  clearly  the  most  ambitious,  and  may  require  design  decisions  that  go  beyond  our 
current  understanding  of  how  to  implement  an  effective  VRC  system.  For  this  reason,  it  is 
probably  most  useful  as  a long-term  goal,  designed  to  keep  VRC  progress  headed  in  the 
right  direction,  rather  than  as  a current  system  definition. 


3.4  VRC  Functional  Requirements 

In  addition  to  simply  providing  the  capability  to  perform  the  services  described  above,  the 
VRC  system  must  do  this  in  the  particular  environment  of  a public  roadway.  This  implies 
certain  functional  requirements  for  the  system  [14].  A list  of  the  functional  requirements 
necessary  to  implement  the  various  IVHS  and  CVO  services  are  detailed  in  this  section. 
Not  all  of  these  requirements  are  needed  to  implement  many  of  the  services  listed.  Rather, 
this  is  a complete  summary  of  the  requirements  for  all  the  IVHS  and  CVO  services.  The 
requirements  may  be  divided  up  into  two  sections:  those  of  the  overall  system  which 
include  the  reader,  communication  between  the  reader  and  transponder,  etc.,  and  those  of 
the  transponder  itself. 


3.4.1  Overall  System 
Multilane  Capabilities 

The  reader  should  have  the  ability  to  monitor  vehicle  activities  on  multilane  highways.  The 
communication  between  the  reader  and  the  vehicle  should  be  two-way.  Furtiiermore,  the 
reader  should  be  able  to  determine  which  traffic  lane  it  is  communicating  with  and 
distinguish  between  transponders  in  different  lanes  passing  the  reader  site  simultaneously. 
The  reader  should  also  be  able  to  actively  select  which  transponder  it  wishes  to 
communicate  with. 


Single  or  Multiple  Reads 

As  the  vehicle  passes  through  the  read  zone,  a single  read  record  should  result  The  reader 
could  also  have  the  option  to  take  multiple  reads  proportional  to  the  amount  of  time  the 
transponder  is  in  the  read  zone.  This  feature  may  be  used  for  future  system  enhancements 
such  as  congestion  monitoring. 


Transponder  Spacing 

The  reader  should  be  able  to  discriminate  individual  transponders  passing  through  the  read 
zone  separated  by  a minimum  distance  of  1.5  m. 


Communication  Data  Rate 

The  rate  of  data  communication  must  be  high  enough  to  allow  the  vehicle  to  transmit  all 
relevant  data  while  traveling  at  speeds  up  to  and  including  160  km/h.  For  some  of  the 
services  mentioned,  the  reader  should  also  have  the  capability  to  write  to  the  transponder  to 
update  the  individual  vehicle’s  records.  Both  read  and  write  must  occur  while  the  vehicle  is 
in  the  communication  zone.  Therefore,  the  communication  rate  must  be  high  enough  to 
allow  the  vehicle  to  both  transmit  and  receive  all  relevant  data  depending  on  the  type  of 
application  or  service  that  is  in  use. 
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Memory  Storage 

Nonvolatile  memory  is  needed  either  on  the  transponder  or  on  an  in-vehicle  computer  to 
store  the  information.  The  size  of  the  memory  must  be  adequate  to  store  all  pertinent 
records  and  data  that  will  be  communicated  to  and  received  from  the  reader.  If  the  data  is 
stored  in  an  on-board  device,  then  the  transponder  must  have  sufficient  storage  capacity  to 
act  as  a temporary  buffer  for  the  received  and  transmitted  data. 


Data  Encryption  and  Fraud  Detection 

The  stored  data  should  be  encrypted  to  insure  the  data  is  not  easily  understood  or  modified 
by  unauthorized  parties.  The  reader  system  should  also  be  able  to  detect  fraudulent 
transactions  and  unauthorized  information  that  is  written  to  the  memory. 


Data  Accuracy 

The  system  must  be  able  to  transmit  data  accurately.  A system  with  high  accuracy  will  not 
allow  transactions  to  appear  valid  when  in  reality  they  are  not  (i.e.,  collecting  funds  from 
the  wrong  account). 

Communication  Reliability 

Finally,  the  communication  between  reader  and  transponder  must  be  reliable.  The 
maximum  number  to  transponders  that  fail  to  be  read  as  they  pass  through  the  read  zone 
should  not  be  more  than  1 in  10^. 


3.4.2  Transponder 
RF  Interference 

The  transponder  should  not  produce  any  RF  interference  or  be  susceptible  to  local  RF 
interference  such  as  electrical  generators,  cellular  telephones,  mobile  pager  units,  two-way 
radios,  etc.  which  may  disrupt  communications.  For  example,  the  transponder  may  be 
frequency  agile  which  would  adjust  the  frequency  used  to  send  or  receive  information. 
Radiated  radio  frequency  power  levels  should  conform  to  federal  standards. 


Communication  Activation  and  Deactivation 

The  transponder  should  be  capable  of  selectively  activating  or  deactivating  communication 
with  the  reader  depending  on  commands  receiv^  from  the  reader  or  site  controller. 


Interface  to  On-Board  Computer  (OBC) 

The  transponder  should  have  a standard  external  interface  to  on-board  computers  and 
devices  on  the  vehicle  through  which  it  would  communicate  up-linked  data.  Such  on-board 
devices  would  be  used  for  data  storage,  dynamic  dispatching,  vehicle  condition 
monitoring,  etc. 
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Power  Supply 

The  transponder’s  power  supply  should  be  independent  of  the  vehicle’s  electrical  system. 
While  certain  features  on  the  transponder  may  utilize  the  vehicle’s  power  supply,  the  basic 
default  operation  should  be  independent. 


External  Displays 

The  transponder  should  have  an  external  display  which  indicates  if  it  is  faulty.  The  display 
would  also  indicate  if  the  transponder  has  been  tampered  with  or  removed  by  unauthorized 
personnel. 


Physical  Requirements 

The  transponder  should  be  able  to  function  under  all  ambient  climatic  conditions,  operating 
environments,  and  in  the  presence  of  normally  occurring  substances  such  as  sand,  salt, 
dirt,  precipitation,  etc.  It  should  meet  the  requirements  for  shock,  vibration,  contaminants, 
etc.  as  defined  by  Military  Standard  810D.  The  transponder  should  operate  and  maintain 
the  integrity  of  its  stored  data  in  temperatures  ranging  from  -60  °C  to  85  °C.  Finally,  the 
transponder  should  operate  reliably  under  prolonged  physical,  radio  frequency,  thermi  and 
ultraviolet  exposure. 


Mounting 

The  transponder  should  be  easily  mounted  to  the  vehicle,  bearing  in  mind  the  roadway 
environment  and  life  expectancy  of  the  transponder.  If  possible,  it  should  conform  to 
preexisting  standards  (i.e.  license  plate  patterns). 


Cost 

The  transponder  unit  should  not  be  overly  expensive  when  mass  produced.  A good  cost 
goal  is  under  $50. 


Life  Span 

In  normal  use,  90%  of  transponders  should  remain  functional  after  5 years  and  80% 
functional  after  10  years. 


3.5  VRC  Technical  Requirements 

In  order  for  a VRC  system  to  perform  the  services  described  earlier,  and  to  meet  the 
functional  requirements  identified  above,  it  must  possess  certain  technical  characteristics. 
These  required  technical  characteristics,  or  technical  requirements,  are  described  here.  Not 
all  of  the  intended  services  require  the  existence  of  all  of  these  technical  requirements.  To 
help  manage  this  complex  requirements  analysis,  a matrix  has  been  constructed  that  maps 
appropriate  technical  requirements  to  the  desired  services. 


24 


VRC  Standard  Recommendations 


System  Requirements 


3.5.1  Technical  Requirement  Descriptions 

The  following  is  a description  of  each  of  the  technical  requirements  used  in  the 
requirements  matrix. 


Off-line  Function 

This  is  a transaction  that  does  not  take  place  as  the  vehicle  passes  an  RF  beacon  in  mainline 
motion.  This  function  would  be  performed  through  the  interaction  of  roadside  computers 
or  terminals  with  a national  database.  Any  data  that  must  be  resident  on  the  vehicle 
transponder  would  then  be  written  to  the  vehicle. 


One-way  Sufficient 

One-way  communication  with  the  vehicle  is  sufficient  for  this  service.  There  is  no  need  to 
write  any  information  to  the  vehicle  tag.  An  example  of  such  a service  would  be  electronic 
toll  collection  where  the  roadside  beacon  queries  that  tag  on  the  vehicle  for  an  ID. 


Two-way  Enhancement 

One-way  communication  with  the  vehicle  is  sufficient  for  this  service,  but  the  service 
would  be  enhanced  if  there  was  two-way  communication  with  the  vehicle.  The  added 
writeability  of  the  tag  would  allow  additional  data  to  be  kept  on  the  tag  and  could  be  used  to 
provide  extra  information  to  the  driver  of  the  vehicle. 


Two-way  Required 

Two-way  communication  with  the  vehicle  is  required  for  this  service.  There  is  information 
which  must  be  updated  on  the  tag  and  information  which  the  driver  must  have  in  order  to 
determine  what  action  he  must  take. 


Lane  Distinction 

The  lane  in  which  the  vehicle  resides  must  be  known  to  direct  its  next  action  (toll 
collection,  border  crossing,  or  bypassing  a weigh  station.) 


Transponder  Memory  Size 

Refers  to  the  total  amount  of  data  storage  (in  bits)  that  is  resident  within  the  transponder 
and/or  which  may  reside  in  other  devices  connected  to  the  transponder  (onboard 
computers,  etc.)  If  the  transponder  is  connected  to  an  onboard  device,  it  can  be  assumed 
that  the  data  storage  within  the  transponder  is  only  required  for  temporary  buffering 
purposes  and  other  uses  not  associated  with  the  onboard  device. 
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OBC  Enhancement 

The  use  of  an  On-Board  Computer  (OBC)  would  allow  enhanced  or  more  sophisticated 
implementation  of  this  service. 


OBC  Required 

The  use  of  an  On-Board  Computer  (OBC)  is  required  to  make  the  required  transactions  and 
store/retrieve  the  required  data. 


Data  Encryption 

Encryption  consists  of  an  algorithm  residing  in  the  fixed  equipment  which  encodes  data 
sent  to  the  transponder  and  decodes  data  received  from  the  transponder.  This  helps  to 
prevent  any  unauthorized  use  of  the  data. 


Multilevel  Security 

The  data  should  have  additional  multilevel  security  when  involving  confidential  or  value 
(monetary)  information. 


Minimum  Data  Rate 

Specifies  the  minimum  data  rate,  in  Kilobits  per  second  (KBS),  required  to  transfer  the 
information  between  the  fixed  equipment  and  the  transponder  on  the  vehicle  while  the 
vehicle  is  in  the  capture  zone  of  the  antenna. 


3.5.2  Requirements  Matrix 

The  following  matrix  (Table  1)  has  been  constructed  to  simplify  the  evaluation  of  various 
VRC  approaches.  It  maps  various  technical  requirements  for  a VRC  implementation 
against  CVO  services  and  potential  IVHS  services. 
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VRC  Recommendations 


DRAFT 


System  Requirements 


3.6  Site  Specific  Requirements 

There  are  a number  of  VRC  system  characteristics  that  cannot  be  viewed  as  required  to 
accomplish  any  particular  service.  However,  in  certain  installations,  it  may  be  found  that 
they  are  important  in  obtaining  successful  system  operation.  These  include  the  following: 


Frequency  Agility 

Systems  with  this  feature  are  better  able  to  accommodate  sources  of  intentional  or 
unintentional  electromagnetic  interference  by  changing  the  roadside  equipment’s  frequency 
to  a clear  channel.  Interference  occurs,  even  with  dedicated  frequency  authorization. 
Interference  often  results  from  high  power  transmitters  tuned  near  the  authorized  frequency 
or  harmonically  related. 


Polarization  Type 

Refers  to  the  RF  polarization  type  that  sends  the  best  signal.  The  signal  is  usually  polarized 
in  the  horizontal  or  vertical  directions.  Circular  polarization  is  also  available. 


Field  Strength 

Refers  to  RF  signal  strength  required  to  make  the  communication  link  between  the  roadside 
beacon  and  the  vehicle  transponder  (this  can  vary  from  a few  milliwatts  to  2 watts). 


Inpavement  Antenna 

The  data  required  for  the  service  can  be  transmitted  to  the  vehicle  satisfactorily  using  an 
inpavement  type  antenna. 


Overhead  Antenna 

The  data  required  for  the  service  can  be  transmitted  to  the  vehicle  satisfactorily  using  an 
overhead  type  antenna. 


Since  the  need  for  a particular  polarization  type,  antenna  type,  frequency  agility,  etc.  is  not 
dictated  by  the  user  service,  and  is,  in  fact,  dependent  on  local  site  variables  (such  as  the 
nature  of  local  RF  interference),  no  general  statement  can  be  made  about  their  applicability 
for  all  installations.  Since  site  characteristics  vary,  it  is  clear  that  systems  offering 
flexibility  in  these  characteristics  (that  is,  choice  of  antenna  types,  etc.)  have  an  advantage. 
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4.  Identification  of  Alternative  Approaches 

Numerous  concepts,  protocols,  designs  and  components  exist  or  are  planned  that  embody 
characteristics  desirable  in  a VRC  system.  The  need  for  the  specification  of  a standard  in  as 
short  a time  as  possible  dictates  that  existing  technologies  be  used  where  available  and 
where  they  meet  the  requirements  presented  earlier.  The  purpose  of  this  section  is  to 
present  the  existing,  planned  or  currently  proposed  standards  that  may  be  applicable,  in 
whole  or  in  part,  to  CVO  VRC  requirements. 

Further,  since  the  practicality  of  employing  a standard  depends,  in  part,  on  the  ability  to 
actually  implement  it  in  real  components  using  existing  technology,  a broad  survey  of  VRC 
systems  and  components  was  performed  to  determine  present  capabilities  and  planned  near- 
term  capabilities  of  various  VRC  technologies.  It  is  important  not  to  define  a 
communication  standard  that  calls  for  performance  of  its  required  components  which  is 
beyond  the  capability  of  systems  that  can  be  fielded. 

Numerous  documents  [3-7,  15-27,  30-32]  and  conversations  with  developers  [28,  29,  33- 
38]  were  used  in  compiling  the  information  in  this  survey.  The  results  of  this  survey 
follow.  Based  on  the  number  of  protocols,  technologies,  and  component  specifications 
examined,  we  believe  the  information  accurately  reflects  the  types  of  alternatives  currently 
available.  An  attempt  has  been  made  to  present  a representative  set  of  approaches.  It 
cannot  be  guaranteed  that  every  approach  has  been  examined,  especially  since  new 
approaches  are  continuously  being  developed. 

4.1  RF  Interface  Protocols 

The  following  standards,  proposed  standards,  or  techniques  have  been  identified  as 
candidates  for  VRC  protocol  standardization.  They  are  described  here  in  no  particular 
order.  In  most  cases,  use  of  the  particular  method  implies  use  of  a particular  type  of 
hardware  (though  not  necessarily  a particular  vendor).  For  this  reason,  the  different 
techniques  are  described  in  the  context  of  an  installation  described  by  the  developer.  Where 
the  method  is  flexible  across  hardware  types,  it  is  noted.  Some  protocols  are  considered 
proprietary  by  their  developers.  The  nonproprietary  aspects  of  these  are  presented  because 
they  give  some  insight  into  other  possible  approaches,  because  licensing  may  be  pursued, 
and  since  proprietary  techniques  are  sometimes  eventually  released  into  the  public  domain. 
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4.1.1  CALTRANS  - Public  Domain 
Communications  Protocol 

The  CALTRANS  protocol  (Figure  1)  for  Vehicle- to-Roadside  Communications  (VRC) 
equipment  uses  a half-duplex  modulated  backscatter  approach  to  permit  two-way 
communications  with  a transponder  [4,  6].  The  protocol  is  designed  to  handle  only  one 
(the  most  dominant)  transponder  per  reader  at  a time.  The  protocol  does  not  address 
multiple  transponder  responses  (no  multiplexing).  The  reader  transmits  a 33  microsecond 
RF  pulse  of  10  “1”  bits  to  activate  the  transponder.  The  reader  then  transmits  a polling 
message  which  provides  information  to  the  transponder  including  the  type  of  transaction  to 
take  place.  The  reader  then  transmits  an  unmodulated  continuous  wave  RF  signal  for  the 
transponder  to  modulate  with  a data  message  while  backscattering  to  the  reader.  When  an 
error  free  message  is  obtained,  the  reader  transmits  an  encoded  Acknowledgment  message 
to  the  transponder  providing  status  information  and  requesting  that  the  transponder  not 
respond  to  the  same  polling  message  again  for  ten  seconds.  This  silencing  of  correctly  read 
transponders  reduces  the  interference  from  multiple  transponders  responding 
simultaneously  to  the  same  reader. 

The  CALTRANS  standard  is  not  proprietary  and  has  been  placed  in  the  public  domain. 


RF  Characteristics 

The  reader  and  transponders  transmit  in  the  902-928  MHz  frequency  band.  Specific 
frequency  and  bandwidth  depend  on  FCC  assignment.  Transponders  will  be  able  to 
operate  at  any  frequency  in  this  band. 

The  reader-to-transponder  data  is  encoded  in  the  RF  signal  using  the  methodology  of 
Manchester  Encoding.  The  binary  bit  1 is  represented  by  a positive  pulse  followed  by  a 
negative  pulse.  The  binary  bit  0 is  represented  by  a negative  pulse  followed  by  a positive 
pulse. 

The  transponder-to-reader  data  is  encoded  in  the  RF  signal  using  a methodology  called 
Frequency  Shift  Keying  (FSK).  The  transponder  baseband  message  signal  modulates  the 
subcarrier  with  a center  frequency  of  900  kHz  and  a frequency  deviation  of  ± 300  kHz. 
The  lower  frequency  (600  kHz)  corresponds  to  a 0 bit  and  the  upper  frequency  (1200  kHz) 
corresponds  to  a 1 bit. 

The  data  rate  of  data  messages  is  300  Kbits  per  second  for  both  the  reader-to-transponder 
and  transponder-to-reader  links. 


Security  Capabilities 

The  protocol  employs  a 32  bit  random  number  that  is  used  by  the  transponder  as  part  of  an 
encryption  algorithm  for  secure  data  communications. 


Error  Checking  Capabilities 

The  protocol  uses  a 16  bit  Cyclic  Redundancy  Check  (CRC)  based  on  the  polynomial 
Xi6  + xi2  + -H  1 to  detect  errors  in  the  transmitted  data. 
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Vehicle  Location  Capabilities 

The  protocol  does  not  specify  how  to  determine  vehicle  location  for  the  purposes  of 
enforcement,  although  it  could  likely  be  accomplished  using  a one  reader  per  lane 
configuration. 


Application  Description:  Vehicle  Transponder 

The  CALTRANS  specified  transponder  is  an  RP  two-way  modulated  backscatter  device 
which  is  encoded  with  a unique  identification  code.  The  transponder  must  be  able  to  be 
turned  on  and  off.  The  memory  size  of  the  transponder  is  not  specified,  as  it  is  application 
specific.  The  transponder  modulation  scheme  is  amplitude  modulation  of  an  RF  carrier 
backscatter  and  Frequency  Shift  Key  modulation  of  the  subcarrier.  The  transponder  must 
be  positioned  at  the  front  of  the  vehicle  with  a clear  line  of  sight  to  the  reader  antenna. 


Application  Description:  Roadside  Reader 

The  reader  is  the  protocol  master  to  trigger  or  activate  a transponder,  read  from  or  write  to  a 
transponder,  and  assure  message  delivery  and  validity.  The  reader  is  intended  to  be 
installed  at  a fixed  location  on  the  roadway. 
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Wake-Up  Polling  Transponder  Acknowledgement 

Signal  Message  Message  Message 


Wake-up  Signal  (Bits) 

10 


1111111111 


Polling  Message  (Bits) 


12 

16 

16 

16 

Header 

Transactbn  code 

Agency  code 

Error  code 

Transponder  Message  (Bits) 


12 

16 

32 

16 

Header 

Transactton  code 

Transponder  IDrtumber 

Error  code 

Acknowledgement  Message  (Bits) 

12 

16 

32 

32 

16 

16 

' Header 

Traisactfon  code 

Transponder  ID  irumder 

Header  ID  code 

iKUiilllll 

Error  code 

Figure  1.  CALTRANS  Format 
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4.1.2  Proposed  Standard  A - Public  Domain 
Communications  Protocol 

This  proposed  standard  consists  of  two  protocol  specifications.  One  is  for  wide-area 
operation  and  is  described  here.  The  other  is  for  lane-based  application  and  is  described  in 

4.1.3. 

This  proposed  standard  for  Vehicle-to-Roadside  Communications  (VRC)  equipment  uses  a 
Slotted  Aloha  Time  Division  Multiple  Access  (TDMA)  protocol  to  permit  two-way 
communications  with  many  vehicles  simultaneously  (Figure  2).  The  Slotted  Aloha 
protocol  is  a priority  slot  system  consisting  of  several  request  slots  and  data  slots  that 
comprise  a data  frame.  The  protocol  frame  structure  consists  of  a Reader  Control  Message, 
4 Data  Message  Slots,  an  Acknowledgment  Message  after  each  Data  Message  Slot,  and  16 
Aloha  Request  Slots.  Each  vehicle  transponder  within  the  communication  area  of  the 
reader  antenna  competes  to  capture  an  Aloha  Request  Slot.  After  the  transponder  has 
successfully  captured  a slot,  the  reader  then  commands  it  to  transmit  its  data  in  one  of  the 
four  Data  Message  Slots.  At  the  conclusion  of  each  transaction,  a positive  confirmation  is 
performed.  If  the  transaction  failed  for  any  reason,  a mechanism  to  repeat  the  transaction  is 
initiated.  If  a collision  occurs  between  transponders  in  trying  to  capture  an  Aloha  Request 
Slot,  each  transponder  in  the  collision  is  required  to  wait  a random  period  of  time  before 
attempting  to  seize  an  Aloha  slot  for  retransmission.  The  protocol  is  also  being  extended  to 
permit  communication  with  HELP  and  CALTRANS  type  tags  during  otherwise  unused 
guard  time  periods.  The  standard  defines  the  structure  of  the  communications  protocol  and 
equipment  performance  requirements.  Message  content  (data)  and  equipment  design  is 
application  specific  and  is  not  in  the  scope  of  the  proposed  standard. 

This  protocol  has  been  placed  in  the  Public  Domain  to  help  encourage  standardization. 

The  protocol  frame  structure  is  described  in  more  detail  below: 

Reader  Control  Message 

The  Reader  Control  Message  assigns  Data  Message  Slots  for  up  to  four  requesting 
transponders  and  issues  a transaction  command  to  each  of  the  four  selected 
transponders. 

Data  Message  Slots 

The  Data  Message  Slots  contain  a data  packet  to  or  from  the  transponder.  Content 
of  the  Data  Message  Slot  is  application  specific.  Unused  bits  in  the  slot  are  set  to 
zero. 

Aloha  Request  Slots 

The  Aloha  Request  Slots  are  used  by  the  transponder  to  notify  the  reader  that  it  is 
present  in  the  communication  zone  and  is  requesting  to  send  information  to  the 
reader. 

Acknowledgment  Message 

The  Acknowledgment  Message  indicates  whether  or  not  the  prior  Data  Message 
Slot  was  received  properly.  All  Data  Message  Slots  either  have  a positive  or 
negative  Acknowledgment  Message. 
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RF  Characteristics 

This  protocol  is  currently  implemented  using  an  active  technology,  with  the  transponder 
incorporating  an  active  transmitter.  The  use  of  an  active  transmitter  allows  for  lower  RF 
power,  wide  area  of  coverage,  and  high  speed  data  rates.  Carrier  frequency  for  the  wide- 
area  protocol  is  country  and  application  specific,  as  well  as  subject  to  FCC  assignment  in 
the  U.S.  The  lane-based  carrier  is  specified  as  ±915  MHz,  subject  to  FCC  assignment. 
There  are  currently  three  RF  versions:  915  MHz  (North  America  and  Australia),  2.45  GHz 
(Asia),  and  5.8  GHz  (Europe  and  Asia). 


Security  Capabilities 

The  protocol  uses  a 64  bit  validation  algorithm  to  protect  against  counterfeiting  or 
tampering  with  the  transmitted  data. 


Error  Checking  Capabilities 

The  protocol  uses  a 16  bit  Cyclic  Redundancy  Check  (CRC)  of  the  form  + X^  -i- 

1 to  detect  errors  in  the  transmitted  data. 


Vehicle  Location  Capabilities 

A proprietary  system  for  tracking  and  determining  the  location  of  the  vehicle  has  been 
developed  and  tested.  It  makes  use  of  the  normal  message  traffic  and  some  additional  off- 
vehicle  hardware  to  make  determinations  of  vehicle  position.  This  could  provide  the  data 
required  to  perform  toll  enforcement. 


Application  Description:  Vehicle  Transponder 

A transponder  using  this  protocol  is  being  manufactured  for  the  Advantage  1-75  project  and 
described  below.  The  transponder  has  512  bits  of  memory  of  which  64  bits  are  factory 
programmed  with  a 32  bit  public  ID  and  a 32  bit  private  ID,  192  bits  are  agency 
programmed,  and  256  bits  are  read/write.  The  transponder  incorporates  a driver  interface 
through  the  use  of  2 LED  signal  lights  and  a beeper  annunciator.  There  is  also  a 9600  baud 
RS-232  serial  link  that  can  be  interfaced  to  an  On-Board  Computer  (OBC),  a smart  card 
device,  the  existing  J-bus  connection  (SAE  and/or  ISO),  driver  displays  such  as  an  LCD, 
and  a voice  annunciator.  This  interface  allows  for  driver  audio/visual  messaging, 
safety/road  sensing  and  monitoring,  and  diagnostic  monitoring  of  the  vehicle’s  condition. 


Application  Description:  Roadside  Reader 

The  reader  is  the  protocol  master  to  trigger  or  activate  a transponder,  read  from  or  write  to  a 
transponder,  and  assure  message  delivery  and  validity.  The  reader  is  intended  to  be 
installed  at  a fixed  location  on  the  roadway.  The  roadside  reader  can  be  integrated  into 
existing  infrastructure  such  as  toll  collection  systems,  truck  weigh  station  systems,  and 
commercial  fleet  computers.  The  same  reader  can  operate  in  the  following  RF  frequency 
bands:  915  MHz  (North  America  and  Australia),  2.45  GHz  (Asia),  and  5.8  GHz  (Europe 
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and  Asia).  The  reader  has  an  RS-232/RS-422  interface  for  application  specific  computer 
systems  and  is  VME  form  factor.  Simple  applications  can  be  handled  directly  without 
additional  computing  power,  but  if  additional  computing  power  is  required,  the  reader  can 
be  integrated  with  additional  computer  processing. 
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Frame  Structure 


Reader  Control 
Message  (ROM) 


Data  Message  Slots  (4) 


Aloha  Request  Slots  (1 6) 


Acknowledgement  Messages  (one  after  each  Data  Message  Slot) 


Reader  Control  Message  (Bits) 


16 

8 

8 

32 

8 

32 

8 

32 

8 

32 

64 

16 

Header 

Type 

Cmd  1 

1D#1 

Cmd  2 

ID  #2 

Cmd  3 

ID  #3 

Cmd  4 

ID  #4 

Seed 

CRC 

Data  Message  (Bits) 


16 

8 

512 

8 

16 

Header 

Typ0 

Message  Data 

Valid 

;ORC 

Acknowledgement  Message  (Bits) 

16  8 16 


Header 


Type 


CRC 


Aloha  Request  Message  (Bits) 


16 

8 

32 

16 

Header 

Type 

iD# 

CRC  : 

Figure  2.  Proposed  Standard  A Format 
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4.1.3  Proposed  Standard  B - Public  Domain 
Communications  Protocol 

This  protocol  for  Vehicle-to-Roadside  Communications  (VRC)  equipment  uses  a Time 
Division  Multiple  Access  (TDMA)  protocol  to  permit  two-way  communications  with  many 
vehicles  simultaneously  in  a lane-based  application.  The  reader  transmits  a 20  |is 
triggering  pulse,  at  a rapid  periodic  rate,  at  a frequency  of  910  MHz.  The  vehicle  mounted 
transponder  is  activated  by  this  pulse  and  in  turn  transmits  its  identification  and  other  stored 
data  to  the  reader  antenna.  This  VRC  system  is  a lane-based  system.  It  is  the  lane-based 
system  that  is  specified  as  the  lane-based  component  of  the  protocol  described  in 
Section  4.1.2 

The  TDMA  protocol  uses  in-pavement  antennas  for  lane-based  applications. 

The  protocol  and  system  described  is  installed  on  the  HELP  Crescent  project  [11,  12,  26] 
that  runs  up  and  down  the  west  coast  from  Washington  state  to  California. 

This  protocol  has  been  placed  in  the  Public  Domain  to  help  encourage  standardization. 


RF  Characteristics 

This  protocol  uses  an  active  technology  to  communicate  between  the  vehicle’s  transponder 
and  the  roadside  reader.  The  use  of  an  active  transmitter  allows  for  large  data  rates.  The 
system  is  capable  of  a 500  Kbits  per  second  data  rate.  The  inpavement  antenna  has  a read 
range  of  approximately  1.2  m in  the  direction  of  travel. 

The  reader  and  transponders  transmit  in  the  902-928  MHz  frequency  band  (tuned  at 
910  MHz),  subject  to  FCC  assignment. 

The  data  is  encoded  in  the  RF  signal  using  the  methodology  of  Manchester  Encoding.  The 
binary  bit  1 is  represented  by  a positive  pulse  followed  by  a negative  pulse.  The  binary  bit 
0 is  represented  by  a negative  pulse  followed  by  a positive  pulse. 


Security  Capabilities 

The  protocol  uses  encryption  in  the  transmitted  data  to  secure  the  information  and  prevent 
counterfeiting. 


Error  Checking  Capabilities 

The  protocol  uses  a 16  bit  Cyclic  Redundancy  Check  (CRC)  to  detect  errors  in  the 
communication  data. 


Vehicle  Location  Capabilities 

The  location  of  the  vehicle  can  be  determined  using  time  multiplexing  with  the  in-pavement 
antennas.  Only  one  antenna  is  reading  at  a time  and  therefore  only  the  vehicle  that  is  in  the 
lane  of  the  active  antenna  is  read.  If  a violation  occurs,  the  lane  that  the  vehicle  is  in  is 
determined. 
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Application  Description:  Vehicle  Transponder 

The  protocol  is  used  in  three  types  of  transponders.  These  are  exterior  transponders, 
interior  transponders,  and  one  with  an  on-board  smart  card  reader. 

The  external  transponder  is  a read/write  Type  n transponder  used  with  the  in-pavement 
antennas  and  has  256  bits  of  memory.  The  partition  between  the  fixed  (read  only)  and 
reprogrammable  (read/write)  data  fields  is  flexible.  An  interface  for  an  on-board  computer 
or  smart  card  reader  is  available  with  the  external  transponder  (Type  III  interface).  The  RF 
communications  rate  for  the  external  transponder  is  500  Kbits  per  second. 

The  internal  transponder  is  read/write  Type  11  transponder  used  with  overhead  antennas. 
The  internal  transponder  is  mounted  to  either  the  dashboard  or  windshield.  An  interface  for 
an  on-board  computer  or  smart  card  reader  is  available  with  the  internal  transponder  (Type 
III  interface).  The  RF  communications  rate  for  the  internal  transponder  is 
500  Kbits  per  second. 

The  smart  card  reader  is  designed  to  mount  on  or  above  the  dash-board  of  the  vehicle.  A 
Type  in  transponder  is  included  in  the  smart  card  reader’s  housing  when  overhead 
antenna’s  are  used.  The  smart  card  reader  has  an  optional  serial  port  for  connection  to 
other  devices.  The  RF  communications  rate  for  the  smart  card  reader  is  500  Kbits  per 
second.  Access  to  the  information  on  the  smart  card  is  9600  baud. 


Application  Description:  Roadside  Reader 

The  reader  is  the  protocol  master  to  trigger  or  activate  a transponder,  read  from  or  write  to  a 
transponder,  and  assure  message  delivery  and  validity.  The  reader  is  intended  to  be 
installed  at  a fixed  location  on  the  roadway.  A single  reader  using  time  multiplexed 
antennas  (in-pavement)  can  interface  simultaneously  with  up  to  eight  lanes  of  traffic.  The 
reader  can  be  tuned  to  operate  in  the  902-928  MHz  frequency  band  (set  at  915  MHz).  The 
reader  has  an  RS-232  interface  and  an  optional  RS-422  interface  with  up  to  4 MB  of  RAM. 
The  reading  speed  of  the  reader  is  500  Kbits  per  second  and  can  have  up  to  5 reads  per 
transponder  at  160  km/h  with  vehicles  present  in  8 lanes  simultaneously. 
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4.1.4  Proposed  Standard  C - Public  Domain 
Communications  Protocol 

This  protocol  for  Vehicle- to-Roadside  Communications  (VRC)  equipment  supports  the 
CALTRANS  open  protocol  and  other  protocols.  The  system  uses  a principle  called 
modulated  backscatter  to  permit  two-way  communications  with  tags.  Note:  The  developer 
uses  the  term  “tag”  for  the  vehicle  mounted  equipment  rather  than  the  term  “transponder.” 
The  principle  of  modulated  backscatter  will  be  described  in  more  detail  in  the  RF 
Characteristics  section.  Three  programmable  modes  of  operation  are  provided  in  the 
system.  These  include  the  CALTRANS/ETC  mode,  the  ATA/ISO  mode,  and  extended 
command  mode.  The  extended  command  mode  includes:  frame  specific  read/write  access, 
600  Kbits  per  second  uplink  communications  rate.  Time  Division  Multiple  Access 
(TDMA),  and  information/status  access. 

Open  Road  Operation  - (Wide  Area^ 

For  the  open  road  application,  a TDMA  protocol  has  been  derived  (Figure  3).  A 
triggering  pulse  consisting  of  a stream  of  10  “1”  bits  followed  by  a 100  \is  delay  is 
used  as  a wake-up  signal.  A polling  message  is  sent  by  the  reader  to  inform  the  tags 
how  many  activation  slots  are  available  in  the  activation  cycle.  The  number  of 
activation  slots  can  be  varied  to  adjust  for  the  traffic  conditions  at  each  reader  site. 
Each  tag  then  calculates  a random  number  to  determine  which  activation  slot  to 
transmit  its  ID  number  in.  If  two  or  more  tags  transmit  in  the  same  activation  slot,  a 
collision  occurs,  but  because  of  the  sensitivity  of  the  reader,  the  reader  is  usually 
expected  to  capture  the  closer  tag  ID.  The  remaining  tags  that  transmitted  in  the 
same  activation  slot  will  transmit  again  when  the  polling  message  in  repeated  during 
the  next  communication  frame.  After  the  reader  has  received  the  ID  numbers  for  the 
tags  that  transmitted  their  ID’s  in  the  activation  slots,  the  reader  goes  into  a direct 
communications  mode  with  each  of  the  specified  tags,  one  at  a time.  The  number 
of  direct  communication  exchanges  is  determined  by  the  number  of  tag  IDs  that 
were  captured  in  the  previous  activation  cycle.  After  the  direct  communications 
with  each  tag  is  completed,  each  tag  is  commanded  to  “sleep”  for  a specified  time  to 
prevent  multiple  transactions  with  one  tag  and  to  reduce  the  noise  level.  After  the 
reader  has  communicated  with  the  last  tag,  it  issues  another  trigger  and  poll 
message  and  another  batch  of  tag  ID  numbers  are  obtained  in  another  activation 
cycle. 

Lane-based  Operation 

For  lane-based  operations,  such  as  Electronic  Toll  Collection  (ETC),  one  reader  is 
installed  per  lane  of  roadway.  Therefore,  there  is  a dedicated  link  between  the 
vehicle  in  the  lane  and  the  reader  in  that  lane.  The  readers  must  be  carefully  tuned 
to  avoid  “cross  lane  reads”  and  still  cover  enough  area  so  that  no  tags  can  slip  by 
without  being  read.  As  the  tag  approaches  the  roadside  reader,  a presence  detector 
signals  the  system  to  turn  on  and  the  reader  sends  out  a single  frequency  RF  signal 
into  the  designated  area  called  the  capture  zone.  Inside  the  capture  zone,  the  tag 
first  enters  a read  envelope  which  is  as  large  as  the  capture  zone  itself.  The  RF 
signal  reflects  off  the  tag  and  returns  to  the  reader  with  the  tag’s  ID  and  other  data 
encoded  in  a modulation  of  the  original  RF  signal.  As  the  tag  enters  the  smaller 
write  envelope  within  the  read  envelope,  the  strength  of  the  RF  signal  reaching  the 
tag  exceeds  a preset  threshold  and  a switch  in  the  tag  flips  to  permit  the  write 
transaction  to  occur  to  the  tag.  Each  lane  on  the  roadway  has  a reader  that  operates 
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at  a separate  frequency.  After  the  transaction  is  completed  and  validated,  the  tag  is 
issued  a command  to  sleep  for  a period  of  time. 

The  protocol  is  in  the  process  of  being  placed  in  the  public  domain. 


RF  Characteristics 

This  protocol  uses  a backscatter  technology  to  communicate  between  the  vehicle’s  tag  and 
the  roadside  reader.  The  tag  does  not  actively  generate  and  transmit  an  RF  signal.  The  tag 
is  a field  disturbance  device  that  sends  information  to  the  reader  by  changing  or  modulating 
the  signal  transmitted  by  the  reader.  This  modification  of  the  signal  includes  the  unique 
identification  code  of  the  tag  and  the  data  that  must  be  exchanged  for  the  required 
transaction.  This  method  of  communication  is  called  modulated  backscatter. 

The  data  is  encoded  in  the  RF  signal  using  a methodology  called  Frequency  Shift  Keying 
(FSK).  Each  of  the  tags  bits  are  data  that  are  composed  of  8 sub-bits,  with  a 0 represented 
by  a 20  kHz  square  wave  signal,  and  a 1 represented  by  a 40  kHz  square  wave  signal. 

The  usable  data  rate  that  is  attained  using  the  modulated  backscatter  approach  with  this 
system  is  300  Kbits  per  second  on  the  downlink  (reader  to  tag  link)  and  600  Kbits  per 
second  on  the  uplink  (tag  to  reader  link). 

In  open  road  operation  the  reader  requires  approximately  6 MHz  of  bandwidth  to  cover 
multiple  lanes  of  highway. 

In  lane-based  operation,  each  reader  requires  a 2 MHz  of  separation  from  the  reader  in  the 
adjacent  lane  to  perform  communications  without  interference. 


Security  Capabilities 

Several  security  features,  including  unique  ID  addressing,  are  used  to  ensure  that  a given 
data  message  only  effects  the  designated  tag.  Read  and  write  password  protection  and  off- 
line authentication  provide  operational  security. 


Error  Checking  Capabilities 

The  protocol  uses  a check  sum  to  detect  any  errors  that  may  occur  during  the  transmission 
or  the  receiving  of  data.  If  an  error  occurs,  data  must  be  retransmitted. 


Vehicle  Location  Capabilities 

The  location  of  the  vehicle  Gane  detection)  is  accomplished  by  installing  one  reader  per  lane 
of  roadway.  Therefore,  there  is  a dedicated  link  between  the  vehicle  in  the  lane  and  the 
reader  in  that  lane.  The  readers  must  be  carefully  tuned  to  avoid  “cross  lane  reads”  and  still 
cover  enough  area  so  that  no  tags  can  slip  by  without  being  read. 
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Application  Description:  Vehicle  Transponder 

The  tag  is  composed  of  the  modulator,  power,  code  generator,  clock,  memory  and  antenna 
circuits  located  on  a single  printed  circuit  board.  The  tag  has  19  general  data  frames  of  128 
bits  each  for  the  storage  of  information.  The  tag  is  powered  by  a 3 AA  size  batteries. 
Battery  life  is  specified  to  be  10  years  and  range  is  specified  to  be  up  to  30  m.  There  are  no 
external  interfaces  with  the  tag.  The  tag  may  be  attached  to  the  vehicle  windshield. 

Application  Description:  Roadside  Reader 

The  reader  is  intended  to  be  installed  at  a fixed  location  on  the  roadway.  The  reader 
receives  a demodulated  signal  from  the  RF  module,  decodes  the  ID  information,  confirms 
message  integrity,  and  transmits  the  code  along  with  any  appended  information  to  the  host 
computer  system.  The  reader  operates  in  the  850-950  MHz  frequency  band  and  has  a 
SCSI-2  communications  interface.  The  reader  has  32K  of  memory,  controls  two  RF 
channels  (for  two  lanes  of  roadway  in  a lane-based  application)  and  supports  two  serial 
ports  and  six  I/O  control  channels. 


Frame  Structure 


Direct  tag 


Trigger  pulse  - Stream  of  10  "1"  bits  to  wake  up  the  tags  within  range  of  the  reader 

Polling  message  - Provides  operating  instructions  which  direct  the  tags'  response 

Activation  cycle  - Tags  transmit  their  ID  number  to  the  reader  during  a random  time  slot 

Direct  communication  - Reader  communicates  directly  with  each  tag  using  ID  addressing 
The  number  of  commtmications  depends  on  the  number  of  tag  ID's  captured  during 
the  previous  activation  cycle. 


Figure  3.  Proposed  Standard  C Format 
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4.1.5  Proprietary  Technique  A 
Communications  Protocol 

This  protocol  for  Vehicle-to-Roadside  Communications  (VRC)  equipment  uses  a Code 
Division  Multiple  Access  (CDMA)  protocol  to  permit  two-way  communications  with  many 
vehicles  simultaneously. 

There  are  two  roadside  antennas  for  the  system.  One  antenna  is  a long-range  (1.6  km) 
broadcast  antenna  and  the  other  antenna  is  a short-range  lane-based  two-way 
communication  antenna.  The  transactions  are  as  follows: 

The  long-range  antenna  initializes  contact  with  the  transponder  and  communicates  the  entire 
toll  schedule.  The  transponder  then  determines  if  there  are  sufficient  funds  for  the  required 
transaction.  In  the  toll  lane,  the  second  antenna  communicates  with  the  transponder  to  debit 
the  toU  amount  in  the  transponder  and  create  a record  of  the  transaction.  The  account 
information  is  stored  in  the  transponder  (decentralized  data  base)  and  transaction 
information  is  sent  back  to  the  antenna  for  audit  purposes. 

Each  transponder  is  shipped  from  the  factory  with  a permanent  Electronic  Serial  Number 
(ESN)  identifying  it  uniquely  in  a potential  universe  of  16  billion  units.  This  ESN  is  the 
identifying  code  that  is  used  in  the  CDMA  protocol. 

There  are  24  memory  locations  for  toU  or  other  account  balances,  a 25th  memory  location  is 
used  for  closed  tollway  applications  (temporary  retention  of  the  entry  point  of  the  vehicle) 
and  a 26th  memory  location  is  used  to  record  every  transaction  that  occurs  (circular  data 
base  of  150  transaction).  CVO  applications  use  two  variable  memory  locations.  The  first 
location  of  32  bytes  can  only  be  modified  by  an  authorized  agent  and  contains  identification 
information  such  as  commercial  account  number,  ICC  registration  number,  license  plate 
number,  or  other  usable  ID.  This  ID  along  with  the  ESN  is  part  of  every  transaction 
between  the  reader  and  the  transponder.  The  second  variable  memory  location  of  32  bytes 
may  be  written  to  at  highway  speed  through  an  RF  link.  This  memory  can  be  used  to  write 
CVO  information  such  as  transport  data  for  interstate  registration  clearance.  Weigh  In 
Motion  (WIM)  data,  or  other  traffic  management  purposes. 

This  protocol  keeps  aU  data  decentralized,  but  is  capable  of  employing  a more  centralized 
approach  if  desired. 

Further  detaUs  are  not  available  because  the  protocol  is  currently  proprietary.  Several  parts 
are  being  considered  for  release  to  the  public  domain  in  the  future. 


RF  Characteristics 

The  reader  transmits  in  the  902-928  MHz  frequency  band  (tuned  at  904.5  MHz),  subject  to 
FCC  assignment. 

The  transponder  receiver  frequency  is  904.5  MHz  and  the  transponder  transmit  frequency 
is  49.86  MHz,  Part  15  type  accepted.  The  904.5  MHz  communication  is  AM  and  the 
49.86  MHz  communication  is  FM  to  take  advantage  of  capture  effect  and  pulse  noise 
rejection.  Both  of  the  antennas  are  etched  on  the  printed  circuit  board  of  the  transponder. 
Other  frequencies  can  be  accommodated  where  necessary. 

The  data  rate  for  both  the  reader  and  the  transponder  is  9600  baud. 
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The  data  is  encoded  in  the  RF  signal  using  the  methodology  of  Manchester  Encoding.  The 
binary  bit  1 is  represented  by  a positive  pulse  followed  by  a negative  pulse.  The  binary  bit 
0 is  represented  by  a negative  pulse  followed  by  a positive  pulse. 


Security  Capabilities 

The  protocol  uses  encrypted  messages  in  both  directions  to  provide  security  capabilities. 

Error  Checking  Capabilities 

The  protocol  uses  a 16  bit  Cyclic  Redundancy  Check  (CRC)  to  detect  errors  in  the 
communication  transmissions. 


Vehicle  Location  Capabilities 

The  location  of  the  vehicle  can  be  determined  by  using  one  short  range  antenna  per  lane. 
The  microprocessor  in  the  transponder  measures  the  field  strength  from  each  antenna  to 
determine  its  position  on  the  roadway.  In  automatic  ticket  issuing  lanes  for  a closed 
ticketing  system,  a valid  signal  will  occur  prior  to  the  ticket  issuing  machine  so  the  lane 
controller  ’^l  prevent  issuing  a ticket. 


Application  Description:  Vehicle  Transponder 

The  transponder  is  a read/write  Type  III  transponder  with  a built  in  microprocessor  (on- 
board computer).  The  transponder  has  separate  receiver/transmitter  for  read  and  write 
ranges  of  up  to  one  mile.  The  CVO  transponder  has  a built  in  2 line  LCD  display  and  audio 
speaker  for  in-cab  notification.  The  transponder  has  a large  memory  storage  (16  Kbits  with 
expandability  up  to  1 Mbits).  The  transponder  has  an  on-board  transponder  interface,  two 
keys  for  programming  and  4 data  input  ports. 


Application  Description:  Roadside  Reader 

The  reader  is  the  protocol  master  to  trigger  or  activate  a transponder,  read  from  or  write  to  a 
transponder,  and  assure  message  delivery  and  validity.  The  reader  is  intended  to  be 
installed  at  a fixed  location  on  the  roadway.  The  reader  can  control  either  4 or  8 lanes  of 
traffic. 
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4.1.6  Proprietary  Technique  B 
Communications  Protocol 

This  protocol  for  Vehicle- to-Roadside  Communications  (VRC)  equipment  uses  frequency 
division  among  several  readers  to  permit  two-way  communications  with  many  vehicles 
simultaneously  using  a specific  type  of  tag.  The  system  uses  a principle  called  modulated 
backscatter  to  permit  two-way  communications  with  tags.  Note:  the  developer  uses  the 
term  “tag”  for  the  vehicle  mounted  equipment  rather  than  the  term  “transponder.”  The 
principle  of  modulated  backscatter  will  be  described  in  more  detail  in  the  Communications 
Link  section.  As  the  tag  approaches  the  roadside  reader,  a presence  detector  signals  the 
system  to  turn  on  and  the  reader  sends  out  a single  frequency  RF  signal  into  the  designated 
area  called  the  capture  zone.  Inside  the  capture  zone,  the  tag  first  enters  a read  envelope 
which  is  as  large  as  the  capture  zone  itself.  The  RF  signal  reflects  off  the  tag  and  returns  to 
the  reader  with  the  tag’s  ID  and  other  data  encoded  in  a modulation  of  the  original  RF 
signal.  As  the  tag  enters  the  smaller  write  envelope  within  the  read  envelope,  the  strength 
of  the  RF  signal  reaching  the  tag  exceeds  a preset  threshold  and  a switch  in  the  tag  flips  to 
permit  the  write  transaction  to  occur  to  the  tag.  Each  lane  on  the  roadway  has  a reader  that 
operates  at  a separate  frequency.  After  the  transaction  is  completed  and  validated,  the  tag  is 
issued  a command  to  sleep  for  a period  of  time. 

Two  RF  modules  can  be  controlled  by  each  reader  and  can  be  time  multiplexed  so  that  two 
lanes  can  be  controlled  by  one  reader.  This  multiplexing  will  cause  a reduction  in  a 
particular  lane’s  maximum  data  rate  below  the  already  somewhat  low  9600  baud  rate. 

The  protocol  is  currently  proprietary. 


RF  Characteristics 

The  protocol  uses  a backscatter  technology  to  communicate  between  the  vehicle’s  tag  and 
the  roadside  reader.  The  tag  does  not  actively  generate  and  transmit  an  RF  signal.  The  tag 
is  merely  a field  disturbance  device  that  sends  information  to  the  reader  by  changing  or 
modulating  the  signal  transmitted  by  the  reader.  This  slight  modification  of  the  signal 
includes  the  unique  identification  code  of  the  tag.  This  method  of  communication  is  c^ed 
modulated  backscatter. 

The  data  is  encoded  in  the  RF  signal  using  a methodology  called  Frequency  Shift  Keying 
(FSK).  Each  of  the  tags  bits  are  data  that  are  composed  of  8 sub-bits,  with  a 0 represented 
by  a 20  kHz  square  wave  signal,  and  a 1 represented  by  a 40  kHz  square  wave  signal. 

The  data  rate  that  is  attained  using  the  modulated  backscatter  approach  is  9600  baud. 

The  frequency  separation  between  adjacent  readers  for  typical  highway  applications  must 
be  at  least  2 MHz  to  prevent  interference.  The  preferred  frequency  band  of  operation  for 
maximum  user  operating  performance  and  flexibility  at  minimum  cost  is  a 10  MHz  wide 
band  in  the  850-950  MHz  band  (and  specifically,  the  902-928  MHz  band). 


Security  Capabilities 

The  protocol  uses  a 12  bit  security  field  to  protect  that  data  that  is  being  written  to  and  read 
from  the  tag 
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Error  Checking  Capabilities 

The  protocol  uses  a check  sum  to  catch  any  errors  that  may  occur  during  the  transmission 
or  the  receiving  of  data.  If  an  error  occurs,  data  must  be  retransmitted. 


Vehicle  Location  Capabilities 

The  location  of  the  vehicle  (lane  detection)  is  accomplished  by  installing  one  reader  per  lane 
of  roadway.  Therefore  there  is  a dedicated  link  between  the  vehicle  in  the  lane  and  the 
reader  in  that  lane.  The  readers  must  be  carefully  tuned  to  avoid  “cross  lane  reads”  and  still 
cover  enough  area  so  that  no  tags  can  slip  by  without  being  read. 


Application  Description:  Vehicle  Transponder 

The  tag  is  composed  of  the  modulator,  power,  code  generator,  clock,  memory  and  antenna 
circuits  located  on  a single  printed  circuit  board.  The  tag  has  two  128  bit  data  frames  of 
memory  for  the  storage  of  information.  One  of  the  frames  is  fixed  (read  only)  and  the  other 
frame  is  variable  (read/write).  The  tag  is  powered  by  a small  lithium  battery  and  can  be 
read  at  distances  up  to  25  m.  There  are  no  external  interfaces  with  the  tag.  The  tag  may  be 
attached  to  the  vehicle  windshield. 


Application  Description:  Roadside  Reader 

The  reader  is  intended  to  be  installed  at  a fixed  location  on  the  roadway.  The  reader 
receives  a demodulated  signal  from  the  RF  module,  decodes  the  ID  information,  confirms 
message  integrity,  and  transmits  the  code  along  with  any  appended  information  to  the  host 
computer  system.  The  reader  operates  in  the  850-950  MHz  frequency  band  and  has  an  RS- 
232  communications  interface.  The  reader  has  32K  of  memory,  controls  two  RF  channels 
(for  two  lanes  of  roadway)  and  supports  two  serial  ports  and  six  I/O  control  channels. 


4.1.7  Protocol  Summary  Matrix 

The  following  matrix  (Table  2)  summarizes  the  information  presented  above  for  the  known 
protocols  that  may  be  applicable  to  a VRC  system. 
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4.2  On-Board  Computer  Interface 

An  on-board  computer  interface  provides  a means  for  the  tag  to  send  or  receive  information 
over  a hardwire  connection  to/ffom  some  device  on  the  vehicle.  This  interface  will  be  used 
to  connect  the  tag  with  a computer  on-board  the  vehicle.  These  interfaces  have  been  used 
for  connection  to  devices  such  as  smart-card  readers  and  driver  displays  as  well.  Several 
manufacturers  produce  tags  with  an  interface  of  this  type,  but  there  is  no  standard  protocol. 

This  section  presents  a summary  of  potentially  useful  communication  protocols  for  this 
purpose. 


CAN 

The  Controller  Area  Network  (CAN)  is  a serial  communications  protocol  which  supports 
distributed  real-time  control  with  a very  high  level  of  security.  Its  domain  of  applications 
ranges  from  high  speed  networks  to  low  cost  multiplexing  wiring.  In  automotive 
electronics,  engine  control  units,  sensors,  etc.  are  connected  using  CAN  with  data  rates  up 
to  1 Mbyte  per  second.  CAN  has  the  following  properties:  prioritization  of  messages, 
guarantee  of  latency  times,  configuration  flexibility,  multicast  reception  with  time 
synchronization,  system  wide  data  consistency,  multimaster,  error  detection  and  signaling, 
automatic  retransmission  of  corrupted  messages  as  soon  as  the  bus  is  idle  again,  and 
distinction  between  temporary  errors  and  permanent  failures  of  nodes  and  autonomous 
switching  off  of  defective  nodes.  Error  checking  is  performed  with  a 1 6 bit  CRC  of  the 
form  X15  + X14  + X‘^^  + X^  +X'^  + + 1. 


SAE  J1850 

The  Society  of  Automotive  Engineers  (SAE)  J1850  is  a serial  communications  protocol 
which  focuses  on  the  network  layer,  data  link  layer  and  the  physical  layer  of  the  OSI  seven 
layer  model.  The  data  rate  is  either  10.4  Kbits  per  second  or  41.6  Kbits  per  second 
dependent  on  the  physical  layer.  The  maximum  length  of  the  network  through  the  vehicle 
is  40  m and  the  maximum  number  of  nodes  on  the  network  is  32.  Error  checking  is 
performed  with  an  8 bit  CRC  of  the  form  -i-  -i-  X?  -i-  -i- 1. 

The  following  table  (Table  3)  summarizes  the  two  protocols  just  described  as  well  as  others 
that  should  be  examined  for  applicability  to  the  VRC  on-board  computer  interface.  Various 
standards  and  other  resources  have  been  used  to  compile  this  matrix  [39,40].  Not  all  are 
typically  thought  of  as  automotive  busses,  however  tiiey  provide  a good  indicator  of  the 
state  of  the  art  in  cost  and  performance,  which  will  aid  in  determining  an  appropriate 
standard  for  VRC.  Other  protocols  exist,  but  these  provide  a good  representation  of  the 
spectrum  of  capabtiities  available. 
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EKisfing  Serial  Inter 

Faces' 

, 

SP50 

CAN 

SERCOS 

I3NET 

BACnet 

SAE  J1850 

Maximum  number 
of  nodes  supported 
on  the  network 

255  on  a link, 
can  be 
extended 
through 
bridges 

2032 

254 

100 

10,000 

(Ethernet),  255 
(ARCNET),  32 
masters  and  222 
slaves  (MS/TP) 

32 

Maximum  distance 
between  nodes 

750  m 

50  m@ 
IMbyte/s 

1 km,  limited 
by  fiber 

2 Ion 

1 km 

40  m network 
length 

Types  of  physical 
media  supported 

Twister  pair, 
coax,  fiber,  RF 

Not  specified 

Fiber 

Twisted  pair 

Twisted  pair, 
coax,  fiber 

single  wire, 
parallel  pair, 
twisted  pair 

Availability  of 
sensor  power  from 
bus 

Yes 

Yes 

No 

Yes  (slaves) 

No 

Yes 

Minimum  message 

1 byte 

0 bytes 

1-16  bytes 

1 byte 

1 byte 

Maximum  raw  data 
rate  on  network 

2.5  Mbyte/s, 

1 Mbyte/s, 
31.25 
Kbytes/s 

1.6  Mbyte/s 

2 Mbyte/s 

9.6  Kbyte/s 

10  Mbyte/s 

10.4  Kbits/s, 
41.6  Kbits/s 
dependent  on 
physical  layer 

Support  for 

Both  are 

N ondeterminis  tic 

Both  are 

Deterministic 

Deterministic 

deterministic  and 

possible 

media  access 

available 

access  through 

media  available 

nondeterministic 
media  access  by 
nodes 

through  a 
token  access 
mechanism 

through  a 
nondestructive 
bit-by-bit 
multiple  access- 
arbitration 
method 

through  master 
synchro- 
nization 
pulses 

single  master 

through  MS/TP 
and  ARCNET, 
only 

nondeterministic 
through  Ethernet 

Estimated  latency 
between 

transmission  of  a 
request  and  receipt 
of  its  response 

<100  ps  for 
selected 
messages 

200  ps 

62.5  ps 

<5  ps  for 
selected 
messages 

<1  ps  for  selected 
messages 

< 300  ps 

Support  for  event- 
driven 

communication 

Yes 

Yes 

No 

No 

Yes 

Yes 

Support  for 
datagram  service 

Yes 

Yes 

Yes 

Yes 

Yes 

Support  for 
connections- 
oriented,  in- 
sequence services 

Yes 

No 

No 

No 

No 

Support  for 
periodic 
invocation  of 
application 
functions 

Yes 

No 

No 

No 

No 

Yes 

Maximum 
permitted 
applications  data 
in  a single 
network  frame 

256  octets 

8 octets 

16  octets 

Unspecified 

510  octets 
(MSyTP),  1500 
octets  (Ethernet) 

Support  for 
multiple  priorities 

Yes 

Yes 

Yes 

No 

Yes 

Yes 

Support  for 
multicast  services 

Yes 

Yes 

Broadcast  only 

No 

Yes 
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Protocol 

complexity 

High,  protocol 
supports 
several  quality 
of  service 
parameters  and 
application 
layer  services 

Simple,  but  the 
protocol  lacks 
the  definition  of 
applic  ation-1  ay  er 
services 

Medium,  403 
application 
messages  are 
defined  and 
initialization 
sequence  is 
complex 

Simple, 
supports 
digits  I/O, 
analog  I/O, 
parameter 
index, 
parameter 
read/write,  and 
totalization 

Medium, 
protocol 
supports 
operations  on 
digital  I/O, 
analog  I/O,  text 
string,  schedule 
alarm,  event, 
file,  and  control 
logic 

Simple, 
addresses  all 
OSI  7 layers, 
focuses  on 
Network,  Data 
Link  and 
Physical 
layers 

Reliability 
against  loss  of 
nodes 

Network  will 
continue  to 
operate  if  there 
is  at  least  one 
node  on  the 
network  that  is 
capable  of 
operating  as  a 
link  active 
scheduler 

Network  will 
continue  to 
operate  with  the 
affected  node 
disconnected 

Loss  of  any 
slave  system 
will  still 
permit 
network 
operation 

Loss  of  any 
slave  will  still 
permit 
network 
operation; 
also,  the 
master  node 
has  a redundant 
bus  interface 
circuit 

Network  will 
continue  to 
operate  with  the 
affected  node 
disconnected 

Network  will 
continue  to 
operate  with 
remaining 
nodes 

Reliability 
against  loss  or 
corruption  of 
information 

16-bit  CRC 

16-bit  CRC 

16-bit  CRC 

8-bit  CRC 

16-bit  CRC 
(MS/TP) 
32-bit  CRC 
(Ethernet) 

8-bit  CRC 

Error  rate 

Low 

Low 

Low 

Low 

Low 

Low 

Cost 

High 

Low 

Medium 

Low 

Medium 

Low 

Table  3:  Overview  of  Existing  Serial  Interfaces 


4.3  FCC  Regulations 

In  the  U.S.,  the  Federal  Communications  Commission  (FCC)  governs  assignments 
relevant  to  these  types  of  systems.  It  is  beyond  the  scope  of  this  document  to  describe  in 
detail  all  of  the  applicable  regulations,  however  we  will  point  out  the  regulations  of  interest. 
Part  90  of  the  Code  of  Federal  Regulations  describes  the  regulations  for  this  type  of 
system.  A proposed  change  in  the  Part  90  regulations  [41]  is  currently  being  evaluated  by 
the  FCC. 

The  current  proposed  changes  in  FCC  regulations  under  47  CFR  Part  90  for  the 
902-928  MHz  frequency  band  include  the  following  new  assignments: 

Short  Range  Vehicle  Identification  Automatic  Vehicle  Location 

902 -904  MHz  904 -912  MHz 

912-  918  MHz  918  - 926  MHz 

926  - 928  MHz 

It  is  important  to  note  the  small  number  of  assignments  for  Short  Range  Vehicle 
Identification  and  the  limited  bandwidth  available  in  each.  Two  assignments  with  2 MHz 
bandwidth  and  one  assignment  with  6 MHz  bandwidth  are  proposed  for  this  function. 

Also  of  interest  is  47  CFR  Part  15  which  governs  other  uses  of  the  902-928  band  for 
operation  without  a license  on  a secondary  basis.  Many  commercial  and  consumer 
products  operate  under  Part  15. 
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4.4  Existing  Systems 

The  purpose  of  the  examination  of  existing  VRC  systems,  specifications  and  equipment  is 
to  determine  the  level  of  capability  currently  available.  This  information  is  considered  in 
the  evaluation  phase  in  determining  what  should  be  included  in  the  standard  and  in 
evaluating  if  a candidate  standard  can  be  implemented  successfully. 

A description  of  relevant  technical  attributes  is  presented.  A chart  follows  documenting  the 
attributes  of  each  surveyed  component. 


4.4.1  Technical  Attributes 
Technology  Type 

This  is  the  physical  method  in  which  the  data  is  transmitted  or  received  from  the 
transponder.  The  two  major  technologies  that  are  used  in  the  Vehicle- to-Roadside 
Communications  (VRC)  equipment  are: 

Active:  There  is  an  active  transmitter  in  the  transponder  that  transmits  the 

transponder’s  information  back  to  the  reader. 

Backscatter:  The  transponder  reflects  and  modulates  the  incoming  signal  to  carry 
the  transponder’s  information  back  to  the  reader.  There  is  no  active 
transmitter  in  the  transponder. 


Communication  Protocol 

This  is  the  method  in  which  communications  traffic  is  sent  between  the  reader  and  the 
transponder.  A Simplex  transmission  is  in  one  direction  only.  A Half-Duplex 
transmission  is  in  both  directions,  but  only  one  direction  at  a time.  A Full-Duplex 
transmission  is  simultaneous  in  both  directions.  A Half-Duplex  transmission  is  found  in 
most  transponder/reader  communications  which  use  an  inqurry/response  protocol. 


Downlink  Modulation 

This  is  the  modulation  scheme  from  the  reader  to  the  transponder.  In  Amplitude 
Modulation  (AM),  the  amplitude  varies  to  represent  I’s  and  O’s.  In  Frequency  Modulation 
(FM),  the  amplitude  remains  constant,  while  the  frequency  varies  to  represent  I’s  and  O’s. 


Uplink  Modulation 

This  is  the  modulation  scheme  from  the  transponder  to  the  reader.  In  Amplitude 
Modulation  (AM),  the  amplitude  varies  to  represent  I’s  and  O’s.  In  Frequency  Modulation 
(FM),  the  amplitude  remains  constant,  while  the  frequency  varies. 
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Binary  Coding  Scheme 

This  is  the  method  in  which  the  data  is  carried  on  the  RF  signal.  There  are  two  main 
coding  schemes  of  concern,  Frequency  Shift  Key  (FSK)  and  Manchester  Encoding. 


Frequency  Shift  Keying 

Using  Frequency  Shift  Keying,  the  data  is  represented  by  a subcarrier  modulation  for  each 
bit.  For  example,  a 0 bit  can  be  represented  by  a 20  kHz  square  waye  signal  and  a 1 bit  as 
a 40  kHz  square  waye  signal.  These  signals  are  carried  on  the  carrier  frequency  of  902- 
928  MHz. 


Manchester  Encoding 

Using  Manchester  Encoding,  the  data  bits  are  represented  by  signal  pulses.  The  0 bit  is 
represented  by  a negatiye  pulse  followed  by  a positiye  pulse  and  the  1 bit  is  represented  by 
a positiye  pulse  followed  by  a negatiye  pulse. 


Protocol  Proprietary 

Is  the  RF  protocol  that  is  used  to  pass  the  information  between  the  reader  and  the 
transponder  proprietary,  or  is  it  accessible  to  yendors  to  manufacture  compatible 
equipment? 


Lane-based  Protocol 

Does  the  system  haye  the  capability  to  perform  lane-based  applications. 


Wide-area  Protocol 

Does  the  system  haye  the  capability  to  perform  wide-area  applications  such  as 
communications  with  seyeral  yehicles  oyer  a wide  area  (seyeral  lanes)  simultaneously. 


Multiplexing  Protocol 

This  is  the  multiplexing  scheme  that  is  used  so  that  the  reader  can  communicate  with  the 
many  transponders  that  are  in  the  antenna  beam.  The  three  multiplexing  schemes  that  are  of 
concern  are  Time  Diyision  Multiple  Access  (TDMA),  Code  Diyision  Multiple  Access 
(CDMA)  and  Frequency  Diyision.  A single  transponder  response  (no  multiplexing)  can 
also  be  used. 


Time  Diyision  Multiple  Access 

In  Time  Diyision  Multiple  Access,  transponders  in  the  communications  area  take  turns  (in  a 
round  robin),  each  one  periodically  getting  the  entire  bandwidth  for  a short  time.  The 
reader  is  only  communicating  with  one  specific  transponder  at  a time  during  a specific  time 
slot. 


51 


VRC  Standard  Recommendations 


Alternative  Approaches 


Frequency  Division 

In  Frequency  Division,  the  frequency  spectrum  is  divided  into  smaller  allocations  so  that 
each  lane  of  traffic  is  equipped  with  a reader  that  communicates  at  a different  frequency 
from  the  neighboring  readers.  This  allows  the  several  readers  to  communicate  with 
transponders  simultaneously  without  interference  between  readers.  For  adjacent  lanes  of 
traffic,  the  readers  typically  need  to  be  separated  by  a band  of  at  least  2 MHz  to  prevent 
interference  from  occurring. 


Code  Division  Multiple  Access 

In  Code  Division  Multiple  Access,  an  identifying  code  is  used  to  separate  a desired  signal  at 
the  receiver  from  other  signals  that  simultaneously  occupy  the  same  frequency  band. 
Unlike  TDMA  or  FD  networks,  a CDMA  network  wiU  accommodate  an  additional  system 
without  revising  the  signal  formats,  although  some  performance  degradation  results. 


Single  Transponder  Response  rNo  Multiplexing") 

The  single  transponder  response  method  of  communications  operates  under  the  assumption 
that  the  reader  will  communicate  only  with  the  transponder  sending  the  strongest  signal 
back  to  the  reader  (the  closest  and  most  dominant  transponder).  The  transaction  is 
completed  with  that  transponder  and  a command  is  issued  to  the  transponder  to  remain 
silent  for  a period  of  time  (usually  10  seconds)  to  allow  communications  with  other 
transponders  in  the  read  area. 


Lanes  per  reader 

This  is  the  number  of  lanes  that  each  reader  can  control.  If  the  reader  controls  more  than 
one  lane,  there  has  to  be  a multiplexing  scheme  involved,  this  is  usually  Time  Division 
Multiple  Access  (TDMA).  This  allows  communication  with  one  lane  of  trific  at  a time. 


Data  rate 

This  is  the  rate  in  which  the  data  is  transferred  by  the  radio  frequency  signal.  The  data  rate 
is  usually  expressed  in  Kbits  per  second  or  baud  (bits  per  second) 


Transponder  Memory  Size 

This  is  the  amount  of  data  storage  (in  bits)  that  is  resident  within  the  transponder  and/or 
which  may  reside  on  other  devices  connected  to  the  transponder  such  as  on-board 
computers  and  smart  card  readers.  If  the  transponder  is  connected  to  an  on-board 
computer,  it  can  be  assumed  that  the  data  storage  within  the  transponder  is  only  required 
for  temporary  buffering  purposes  and  other  uses  not  associated  with  the  on-board  device. 
The  first  number  in  parentheses  is  the  amount  of  read  only  memory  on  the  transponder. 
The  second  number  in  parentheses  is  the  amount  of  memory  that  can  be  written  to  via  the 
RF  link  (writeable). 
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Transponder  Size 

This  is  the  physical  size  of  the  transponder.  The  numbers  correspond  to  length,  width  and 
height  and  is  expressed  in  centimeters.  The  transponder  should  not  be  of  a size  so  large 
that  it  is  cumbersome  and  difficult  to  mount  correctly. 


Transponder  Weight 

This  is  the  physical  weight  of  the  transponder  in  grams. 

Price  of  Transponder 

This  is  the  price  of  the  transponder  as  it  is  currently  produced  by  the  manufacturer.  A good 
cost  goal  for  the  transponder  should  be  less  than  $50  when  mass  produced. 


Transponder  Mounting  Location 

This  is  the  location  that  the  transponder  must  be  mounted  in  order  to  operate  correctly. 
Transponders  are  usually  mounted  either  on  the  front  bumper  of  the  vehicle  or  on  the 
vehicle  dash. 


Transponder  Type 

Type  I,  Type  II,  and  Type  III  are  labels  commonly  used  to  differentiate  transponder 
capabilities. 

A Type  I transponder  is  capable  of  only  transmitting  data  (has  fixed  code  only). 

A Type  11  transponder  can  store  new  data  received  from  the  roadside  reader  (has  fixed  and 
reprogrammable  fields). 

A Type  HI  transponder  is  capable  of  full  two-way  communications  with  the  roadside  via  a 
link  to  an  on-board  computer  or  smart  card  reader  (capable  of  bi-directional 
communications  between  the  roadside  and  an  on-board  computer  or  smart  card  reader). 


Visual  Display  on  Transponder 

A visual  display  on  the  transponder  (be  it  a LCD  display  or  LED  light  display)  allows  direct 
communication  with  the  driver  of  the  vehicle. 

Audio  on  Transponder 

An  audio  signal  that  is  generated  by  the  transponder  allows  direct  communication  with  the 
driver  of  the  vehicle. 


Optional  Ports  on  Transponder 

Optional  ports  on  the  transponder  aUow  the  transponder  to  interface  with  other  devices  on 
the  vehicle  such  as  on  on-board  computer,  a smart  card  reader,  or  the  vehicle’s  J-bus. 
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Power  Supply 

This  is  the  method  in  which  the  transponder  chip  receives  its  power.  The  transponder  may 
be  battery  powered,  be  powered  by  the  vehicles  power,  or  be  powered  by  the  energy  in  the 
signal  generated  by  the  reader  (some  backscatter  transponders  use  this  method  of  powering 
the  transponder). 


Battery  Life 

This  is  the  life  expectancy  of  the  internal  battery  that  powers  the  transponder’s  circuitry. 


Battery  replaceable  by  user 

If  the  transponder  is  powered  by  an  internal  battety,  can  it  be  accessed  and  replaced  by  the 
owner  of  the  transponder. 


Nominal  RF  Power  - Reader 

This  is  the  maximum  power  output  of  the  reader  at  the  reader  antenna.  This  is  limited  by 
the  FCC  regulations  for  Radio  Frequency  devices.  Most  readers  have  to  be  FCC  licensed 
for  the  site. 


Security 

This  is  the  method  in  which  the  data  is  secured  within  the  transponder  and  over  the  RF  link 
to  prevent  tampering,  falsification  and  unauthorized  access  of  data. 


Error  Checking 

This  is  the  method  that  is  employed  to  assure  that  the  data  transfer  between  the  reader  and 
the  transponder  occurs  without  error.  The  methods  of  error  checking  include  Cyclic 
Redundancy  Checks  (CRC)  and  Checksums. 


Operating  Temperatures 

This  is  the  temperature  range  at  which  the  transponder  will  function  properly  and  maintain 
the  integrity  of  its  stored  data. 


Operating  Range 

This  is  the  range  at  which  communications  can  accurately  take  place  between  the  stationary 
roadside  reader  and  the  mobile  transponder  that  is  mounted  on  the  vehicle.  The  operating 
range  may  dictate  the  data  rate  which  is  required  for  the  RF  communications.  If  the 
operating  range  is  small  (1.2  m for  some  in-pavement  antenna  configurations)  the  data  rate 
needs  to  be  large  (500  Kbits  per  second)  to  accomplish  the  required  data  transaction 
between  the  roadside  reader  and  the  vehicle  while  the  vehicle  is  in  range.  In  actual 
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installations,  range  may  be  affected  by  many  factors  including  antenna  design  and 
orientation,  terrain  characteristics,  and  presence  of  interfering  signals  or  noise. 

Operating  Speed 

This  is  the  maximum  vehicle  speed  supported  by  the  system. 

Polarization 

This  is  the  transponder  polarization  technique. 


RF  Frequency 

This  is  the  carrier  frequency  that  is  used  to  transmit  the  data  between  the  roadside  reader 
and  the  vehicle  transponder.  This  is  usually  accomplished  in  the  902-928  MHz  frequency 
band. 


Frequency  Agility 

This  is  the  ability  for  the  reader  to  adjust  the  frequency  in  which  it  transmits  to  the 
transponder  and  the  frequency  that  the  transponder  transmits  to  the  reader.  This  is 
normally  only  accomplished  with  a backscatter  system  in  which  the  transponder  reflects  the 
incoming  signal  from  the  reader  back  to  the  reader.  A frequency  agile  system  allows  the 
reader  to  make  adjustments  if  there  is  local  interference  in  another  frequency. 


Bandwidth  of  Signal 

This  is  the  required  amount  of  frequency  bandwidth  that  is  required  to  transmit  the  data  at 
the  specified  data  rate. 


Frequency  separation  per  lane 

This  is  the  frequency  separation  required  between  adjacent  readers  so  that  there  is  no 
interface  between  them.  Normally  this  is  only  required  in  a backscatter  system  where 
Frequency  Division  is  required  to  operate  multiple  lanes  on  a tollway. 


Lane  detection 

This  is  the  ability  of  the  system  to  detect  in  which  lane  a specific  vehicle  is  located.  This  is 
required  for  toll  systems  and  for  enforcement.  There  are  several  methods  for  determining 
which  lane  a specific  vehicle  is  located.  One  dedicated  reader  per  lane,  the  use  of 
inpavement  antennas,  and  calculations  from  several  incoming  signals  can  be  used  to  located 
the  vehicle.  This  is  not  as  important  for  CVO  capabilities  as  it  is  for  ETC  capabilities. 
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Type  of  Data  Base 

This  is  the  type  of  data  base  that  the  transponder  uses.  If  the  transponder  only  holds  an 
identification  number,  this  number  must  be  used  to  located  the  required  information  from  a 
central  database.  If  the  transponder  holds  the  required  data  for  the  transaction,  there  is  no 
need  to  go  to  a centralized  data  base  for  information.  This  is  called  a decentralized  system 


Overhead  Antenna  Available 

Overhead  antennas  can  be  used  with  transponders  which  are  mounted  on  the  vehicle’s  dash 
board  or  on  the  front  bumper.  Copper  coated  windows,  used  for  instant  defrost  in  some 
modem  automobiles,  can  prevent  communications  between  an  overhead  antenna  and  a dash 
mounted  transponder. 


Inpavement  Antenna  Available 

Inpavement  antennas  can  be  used  with  transponders  that  are  mounted  on  either  the  front 
bumper  or  under  the  vehicle. 


4.4.2  Technical  Attributes  Matrix 

The  following  matrix  (Table  4)  presents  the  relevant  technical  attributes  for  the  systems 
examined  in  this  survey. 
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5 . Recommendations 

5.1  Evaluation 

In  this  section  we  address  the  issues  requiring  resolution  in  order  to  form  useful 
recommendations  for  VRC  for  CVO.  In  this  effort  we  draw  on  the  requirements 
documented  in  Section  3 and  on  the  available  alternative  approaches  documented  in  Section 
4 in  identifying  the  issues  and  potential  solutions.  The  various  issue  areas  presented  are 
those  that  became  evident  to  us  in  the  process  of  examining  both  the  requirements  and  the 
alternative  approaches.  Resolution  of  these  issues  in  the  context  of  CVO  is  the  basis  for 
our  recommendations  presented  in  Section  5.2.  After  describing  some  important 
assumptions,  we  consider  the  various  issues  and  present  the  strengths  and  weaknesses  of 
possible  solutions. 

5.1.1  Assumptions 

Several  assumptions  have  been  made  that  serve  to  bound  this  evaluation  effort,  establish 
the  priorities  of  evaluation  criteria  and  help  to  ensure  that  the  resulting  recommendations 
will  clearly  address  the  problems  in  the  VRC  for  CVO  domain  that  are  of  the  greatest 
concern  to  the  FHWA. 

A major  area  of  concern  for  the  FHWA  is  the  deployment  of  incompatible  VRC  systems.  It 
is  a goal  that  VRC  incompatibilities  due  to  technology  must  be  eliminated  and  therefore  the 
recommendations  provided  must  support  eliminating  these  incompatibilities. 

It  is  also  a goal  of  FHWA  to  act  as  quickly  as  possible  in  addressing  the  compatibility 
problems.  For  this  reason,  a priority  is  placed  on  standards,  protocols  and  technologies 
that  are  available  immediately,  or  to  a somewhat  lesser  extent,  that  will  be  available  soon. 

Another  assumption  is  that  the  recommendations  for  standardization  must  support  the  User 
Services  for  CVO  and  other  requirements  documented  in  Section  3,  with  additional 
consideration  given  to  standards,  protocols  and  technologies  that  can  address  future  needs 
(such  as  rVHS  functions)  as  weU. 

Where  other,  more  specific,  assumptions  are  made  they  will  be  pointed  out  in  the 
evaluation. 

5.1.2  User  Requirements 

Table  5 presents  a matrix  of  user  requirements  versus  the  numerous  systems  examined. 
The  purpose  of  this  table  is  not  to  support  a recommendation  of  any  particular  system  or 
type  of  system,  but  rather  to  document  the  ability  of  the  current  state  of  VRC  technology  to 
address  the  requirements  of  CVO,  and  to  some  extent,  other  IVHS  services.  It  serves  to 
help  determine  what  capabilities  or  characteristics  are  reasonable  to  include  in 
recommendations  for  standardization.  Further,  it  can  be  used  to  verify  that  the 
recommendations  made  can  be  addressed  by  existing  technology  and  systems. 

5.1.3  RF  Technology 

Table  4 presents  the  characteristics  of  a great  number  of  VRC  systems.  Two  distinctly 
different  approaches  are  used  in  implementing  the  tag's  abihty  to  send  data  to  a reader.  One 
approach  used  is  the  modulated  backscatter  technique  and  the  other  is  the  on-tag  active 
transmitter  approach.  These  two  approaches  are  fundamentally  incompatible.  That  is. 
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backscatter  and  active  components  (tags  or  readers)  cannot  communicate  with  each  other, 
since  they  each  employ  different  principles  of  operation.  Some  consideration  has  been 
given  to  employing  both  technologies  in  a single  system,  but  we  are  aware  of  no  existing 
devices  that  currently  employ  this  technique  and  its  overall  practicality  is  not  clear.  We 
present  here  what  we  feel  are  the  most  important  and  relevant  strengths  and  weaknesses  for 
each  of  these  techniques  for  CVO. 


Backscatter 

Because  a backscatter  system's  tag  sends  its  data  by  modulating  it  onto  its  reflection  of  a 
continuous  wave  received  from  the  reader,  the  frequency  of  the  signal  received  by  the 
reader  is  exactly  the  same  as  that  sent  by  the  reader.  This  means  that  within  some  bounds, 
the  reader  can  select  the  frequency  for  operation.  Thus,  a degree  of  frequency  agility  is 
offered  by  employing  this  technique.  Frequency  agility  has  the  potential  for  allowing 
different  frequencies  to  be  selected  to  avoid  interfering  signals  as  well  as  to  avoid 
frequencies  used  by  other  similar  systems,  without  requiring  a change  in  the  vehicle  tag. 
This  is  an  advantage  not  shared  by  tags  containing  an  active  transmitter  designed  to  transmit 
on  a single  frequency,  as  are  all  the  active  systems  examined  here. 

However,  several  related  issues  need  to  be  considered  in  determining  just  how  much  of  an 
advantage  this  is  for  near  term  CVO  VRC  adoption.  First,  backscatter  tags  deployed  for 
U.S.  operation  typically  operate  in  the  902-908  MHz  frequency  range,  with  the  inherent 
agility  permitting  them  to  operate  anywhere  within  that  band.  The  ability  to  use  this  agility, 
though,  is  partly  dependent  on  FCC  rules,  some  of  which  are  under  consideration  for 
change  (see  Section  4.3).  As  an  example  of  the  problem.  Proposed  Standard  C (Section 
4.1.4)  for  a wide-area  implementation  using  backscatter  requires  6 MHz  of  bandwidth.  The 
proposed  FCC  mles  only  allocate  one  assignment  for  short  range  vehicle  identification  that 
can  accommodate  this  (912-918  MHz).  Since  under  the  proposed  rules,  no  other 
assignment  is  available  for  a move,  the  agility  advantage  is  largely  lost.  It  should  also  be 
not^  even  under  the  present  rules,  it  is  not  guaranteed  that  one  can  avoid  interference  by 
moving  within  the  902-928  MHz  band.  Many  commercial  unlicensed  spread  spectrum 
devices  are  available  that  operate  in  this  band,  some  using  the  entire  26  MHz  bandwidth  for 
high  data  rate  communications.  If  a different  band  altogether  becomes  available  for  VRC,  it 
could  help  the  congestion  problem,  but  even  a backscatter  system  would  require  new  tags, 
since  the  agility  does  not  provide  for  a change  to  another  band. 

Another  advantage  of  the  backscatter  technology  stems  again  from  the  fact  that  the  signal 
received  by  the  reader  is  a reflection  of  a signal  sent  by  the  reader.  Because  of  this,  the 
signal  win  have  experienced  an  attenuation  over  twice  as  much  distance  as  it  would  have 
had  it  originated  from  a transmitter  on  the  tag.  Since  received  power  drops  as  the  fourth 
power  of  the  distance,  this  distance  is  significant.  This  effect  has  been  exploited  in 
differentiating  between  tags  in  different  lanes  in  lane-based  toll  applications,  where  lane 
determination  is  important  for  enforcement.  How  this  effect  can  be  used  in  wide-area 
implementations  in  a way  that  results  in  an  advantage  over  active  systems  is  not  clear. 

In  considering  standards,  it  is  a strength  that  the  backscatter  technique  for  lane-based 
operation  has  already  been  adopted  as  a standard  by  the  state  of  California.  Known  as  the 
CALTRANS  standard,  it  is  formally  documented  and  in  the  public  domain. 

For  implementation  of  wide-area  backscatter  systems.  Proposed  Standard  C (Section 
4.1.4)  is  being  placed  in  the  public  domain  by  its  developer.  This  is  not  yet  formally 
described  in  public  documents,  nor  has  it  been  submitted  to  any  formal  standards  body. 
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This  appears  to  be  a very  flexible  protocol  for  wide-area  use.  According  to  the  developer, 
testing  at  the  prototype  stage  has  been  performed.  No  fielded  implementations  exist. 

Because  of  the  use  of  reflected  signals,  the  reader  for  a backscatter  system  must  transmit 
more  power  than  is  required  for  an  active  system.  In  general,  requiring  more  power  is  a 
disadvantage,  in  that  it  increases  the  likelihood  of  interference  with  other  systems  and  adds 
more  energy  to  an  already  very  crowded  band. 


Active 

Active  tags  use  a transmitter  on  the  tag  that  produces  an  RF  signal  that  carries  information 
to  the  reader.  (Reception  of  data  by  the  tags  is  performed  in  the  same  way  for  both  active 
and  backscatter  systems,  using  an  on-tag  receiver.)  Since  this  transmission  originates  on 
the  tag,  the  communications  path  for  cairying  data  from  the  tag  to  the  reader  is  the  vehicle 
to  reader  distance.  A path  from  the  reader  to  the  tag  and  back  to  the  reader  is  not  required 
as  with  backscatter.  TTie  result  is  a lower  power  requirement  for  reader  transmissions. 

Since  the  tag  to  reader  signal  originates  on  the  tag,  rather  than  being  a reflection  of  a reader 
signal,  its  frequency  is  determined  by  the  tag.  Active  tags  are  viewed  as  fixed-frequency 
devices,  without  the  frequency  agility  advantage  of  backscatter  tags. 

The  inclusion  of  a transmitter  on  the  tag  adds  complexity,  however  this  has  not  been 
reflected  in  the  tag  cost  data. 

Lane  distinction  methods  have  been  developed  for  both  lane-based  and  wide-area  modes  of 
operation  of  active  systems,  using  characteristics  of  the  signals  received  from  the  tags  to 
deduce  position. 

In  considering  standards,  ASTM  is  currently  working  on  a standard  that  includes  Public 
Domain  Standard  A (Section  4.1.2)  to  specify  wide-area  operation.  Public  Domain 
Standard  B (Section  4.1.3)  for  lane-based  operation  is  supported  within  Public  Domain 
Standard  A to  support  communications  with  tags  that  operate  with  that  protocol.  It  is  an 
advantage  that  both  of  these  are  associated  with  CVO  implementations,  Public  Domain 
Standard  B with  the  HELP  program,  and  Public  Domain  Standard  A with  the  1-75 
program.  Further,  effort  is  being  made  under  the  ASTM  group  to  accommodate 
communications  with  both  active  and  CALTRANS  type  backscatter  tags  within  the 
protocol.  This  could  lead  to  commonalty  between  the  CVO  hardware  and  the  much  greater 
number  of  ETTM  applications. 

In  their  respective  wide-area  configurations,  the  active  approach  yields  a bandwidth 
advantage,  with  its  developer  claiming  a bandwidth  requirement  of  1.5  MHz  for  a wide- 
area  implementation.  The  developer  of  Public  Domain  Standard  C for  wide-area  backscatter 
specifies  a 6 MHz  bandwidth  requirement 

Finally,  because  an  active  tag  has  aU  the  hardware  on  it  necessary  to  ttansmit,  it  can  send  a 
message  without  requiring  a reader  to  provide  the  CW  signal.  Though  all  the  examined 
protocols  place  the  reader  in  charge  of  the  data  exchange,  and  in  fact  currently  require  the 
reader  to  activate  the  tag,  the  active  tag  itself  has  the  capability  for  future,  vehicle  initiated 
communications,  such  as  emergency  messaging. 


62 


VRC  Standard  Recommendations 


Recommendations 


5.1.4  Protocols 

Section  4 includes  descriptions  of  communications  protocols  that  are  in  use,  being  tested, 
or  are  proposed  for  use  at  the  RF  interface  in  the  CVO  application,  each  possessing 
strengths  and  weaknesses.  As  we  evaluate  these  in  the  context  of  the  FHWA  requirements 
and  CVO  needs,  we  are  able  to  identify  advantages  and  disadvantages  of  various 
approaches  which  will  be  considered  in  our  recommendations. 

Two  different  types  of  communication  are  represented  in  the  various  protocols.  These  are 
lane-based  and  wide-area  techniques. 


Lane-based 

Lane-based  protocols  are  designed  to  communicate  with  a single  vehicle  in  a particular  lane 
using,  at  a minimum,  an  antenna  installed  in  each  lane.  Multilane  implementations  rely  on 
coordination  of  the  readers  activities  and  physical  properties  of  the  installation  (lane 
separating  barriers,  antenna  pattern  and  range  control,  etc.  to  avoid  cross-lane  reads,  since 
the  protocol  itself  operates  independently  in  each  lane.  A multilane  configuration  operates 
as  multiple,  point-to-point  links. 

One  advantage  of  a lane-based  system  is  that  a clear  line-of-sight  path  between  a vehicle 
and  a lane's  antenna  is  easy  to  obtain,  since  each  vehicle  will  pass  the  lane's  antenna 
without  any  shadowing  problems  caused  by  other  vehicles. 

Another  strength  is  that  protocols  exist  for  communication  in  a lane-based  topology  for 
both  backscatter  (CALTRANS)  and  active  systems  (Public  Domain  B). 

A disadvantage  of  lane-based  systems  is  the  requirement  for  dedicated  equipment  required 
for  each  lane.  An  antenna  must  be  able  to  communicate  with  each  lane,  and  multiple 
readers  may  be  required  to  cover  all  lanes.  Addition  of  lanes  requires  addition  of 
equipment.  Additions  or  modifications  to  roadways  are  required  for  lane-based 
installations. 

The  physical  zone  in  which  vehicle  to  reader  communication  can  take  place  is  small  by 
design,  in  order  to  minimize  cross-lane  reads.  This  has  the  negative  side  effect  of  limiting 
the  time  available  for  communication  as  a vehicle  passes  at  high  speed. 

Minimizing  cross  lane  reads  typically  involves  examining  each  incoming  signal  at  the  reader 
and  selecting,  by  various  algorithms,  the  one  believed  to  be  from  the  nearest  vehicle.  This 
adds  complexity  and  is  subject  to  some  error.  On  the  other  hand,  the  conclusion  that  the 
message,  and  the  identification  within  it,  came  from  the  vehicle  in  a specific  lane  can  be 
used  for  enforcement  purposes. 


Wide-area 

Wide-area  protocols  are  designed  to  communicate  with  multiple  vehicles  in  any  lane  in  their 
coverage  area  using,  at  a minimum,  a single  antenna  typicdly  installed  at  the  side  of  the 
roadway.  Coordination  of  the  message  traffic  is  based  on  information  in  the  protocol  itself, 
with  provisions  made  for  dynamically  assigning  communication  time  slots  and  dealing  with 
message  collisions. 
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An  advantage  of  a wide-area  system  is  the  minimal  impact  on  the  roadway.  Multiple 
vehicles  can  communicate  widi  a single  roadside  antenna  location  without  requiring 
modifications  to  the  road  or  use  of  antennas  in  each  lane.  An  additional  lane  can  be 
included  for  use  without  addition  of  hardware,  providing  the  range  of  the  roadside  system 
is  sufficient 

The  size  of  the  communications  zone  is  typically  over  30  m and  could  be  more  depending 
on  the  frequency  and  power  used.  This  provides  for  longer  possible  communications  times 
that  could  be  needed  for  transfer  of  large  data  files  with  multiple  vehicles  at  high  speed. 

Protocols  exist  for  wide-area  topologies  under  both  active  and  backscatter  technologies. 

A disadvantage  of  a wide-area  system  is  the  possibility  of  a vehicle  being  shadowed  from 
the  reader  antenna  by  another  vehicle.  More  than  one  antenna  or  reader  might  be  needed  in 
some  situations. 

Since  the  protocol  handles  communications  with  any  vehicle  in  any  lane  and  does  not  force 
a determination  of  the  lane  occupied  by  a communicating  vehicle,  lane  determination,  if 
required,  must  be  determined  by  some  other  means.  Several  mechanisms  have  been 
employed  by  various  developers.  None  are  in  the  public  domain. 


5.1.5  Data  Models 

Section  3.3  introduced  the  use  of  three  different  models  of  CVO  VRC  implementations  to 
help  evaluate  the  capabilities  of  alternative  approaches.  Table  5 includes  an  indication  of 
the  ability  of  each  currently  available  alternative  system  to  support  each  of  the  three  data 
models  for  VRC  implementation. 

All  systems  are  capable  of  supporting  the  requirements  of  a Model  1 scenario.  Many,  but 
not  all  systems  can  support  Model  2 operation.  This  is  important  since  this  is  the  likely 
near-term  implementation  model.  Those  that  could  not  support  Model  2 fell  short  because 
they  lacked  read/write  capability  or  had  insufficient  on-tag  memory.  In  evaluating  the 
ability  to  support  future  CVO  needs,  it  is  encouraging  to  note  that  a small  but  significant 
number  of  systems  are  able  to  support  Model  3 requirements.  It  is  also  important  to  note 
that  the  few  systems  that  can  support  Model  3 behavior  are  not  all  the  same  type,  for 
example,  both  active  and  backscatter  systems  are  represented. 


5.1.6  On-Board  Computer  Interface 

The  performance  requirements  of  this  interface  are  not  yet  clear.  An  upper  limit  on 
performance  is  the  tag-to-reader  data  rate,  since  there  is  probably  no  need  to  communicate 
with  the  tag  at  a rate  greater  than  that.  At  the  lower  end,  there  are  certainly  functions  that 
could  be  performed  using  a very  simple  RS-232  link  operating  at  9600  baud.  However, 
if  one  considers  transferring  files  of  considerable  length  while  a vehicle  is  in 
communication  with  a reader,  faster  techniques  are  necessary.  It  is  possible  that  only  a 
smaU  incremental  cost  over  that  of  lower  performance  systems  will  provide  enough 
performance  to  permit  the  higher  data  rates  that  will  likely  be  needed  for  future  IVHS 
applications. 

At  this  time  no  strong  preference  for  a particular  technique  is  being  put  forth  by  any 
developer.  Common  among  currently  available  tags  are  simple  serial  RS-232  interfaces 
and  the  higher  performance  SAE  J1850  interface.  RS-232  interfaces  supporting  up  to  19.2 
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kbaud  are  easily  available.  J1850  offers  a current  rate  of  up  to  41.6  Kbits  per  second.  A 
future  125  Kbits  per  second  version  is  being  pursued.  Well  beyond  these  in  performance 
are  other  standard  interface  techniques  currently  being  used  or  planned  for  fieldbus 
communications,  typically  among  controllers  and  industrial  devices.  The  CAN  bus  for 
example  can  support  communications  at  rates  to  1.6  Mbytes  per  second.  A rate  such  as  this 
would  allow  re^-time  communication  with  the  on-board  computer  at  the  maximum  tag  RF 
data  rate. 

5.2  Conclusions  and  Recommendations 

In  Section  3 we  utilized  numerous  sources  of  information  to  document  the  necessary 
technical  attributes  of  a VRC  system  that  are  required  for  it  to  perform  specific  CVO 
functions.  Further,  attributes  which  might  be  needed  for  future  IVHS  functions  were 
considered  in  an  effort  to  determine  the  future  demands  on  a VRC  system.  Three  data 
models  were  defined  that  essentially  form  three  different  groupings  of  CVO  functions. 
These  models  provide  a means  to  compare  system  capabilities  to  three  possible  and 
increasingly  sophisticated  implementation  configurations.  The  models  represent  the 
possible  evolution  of  CVO  VRC  systems  from  the  present  into  the  future.  The  CVO  (and 
future  IVHS)  user  services  that  were  determined  were  then  documented  in  a matrix  (Table 
1)  that  indicates  technical  characteristics  or  requirements  that  must  be  present  to  perform 
each  service. 

In  Section  4 we  documented  the  technologies  that  are  available  or  expected  to  be  available 
soon  for  VRC  implementations.  First,  we  examined  a number  of  communications 
protocols  for  the  tag-to-reader  RF  interface  and  documented  their  important  characteristics. 
The  most  important  parameters  of  each  protocol  were  summarized  in  Table  2.  Similarly, 
the  capabilities  of  currently  used  on-board  computer  interfaces  and  of  other  standard 
communication  interfaces  that  might  be  considered  for  use  as  an  on-board  computer 
interface  were  presented  in  Table  3. 

Numerous  VRC  systems  were  examined  in  order  to  obtain  an  understanding  of  the  current 
abilities  of  VRC  for  CVO,  and  to  determine  what  capabilities  might  be  reasonably  expected 
in  the  near  future.  The  characteristics  of  the  examined  systems  were  documented  in 
Table  4. 

We  began  our  analysis  in  this  section,  with  a statement  of  assumptions  and  a description  of 
specific  areas  which  require  resolution  in  order  to  eliminate  incompatible  VRC  systems 
within  CVO.  With  the  information  just  described,  documenting  the  user  services  and  their 
technical  requirements,  and  the  technical  characteristics  of  available  systems,  we  are  able  to 
present  here,  in  Table  5,  a matrix  showing  the  degree  to  which  current  and  expected  near- 
term  systems  can  provide  the  required  CVO  services.  In  addition,  the  ability  of  the 
examined  systems  to  accommodate  the  needs  of  the  three  implementation  Data  Models  is 
included.  Similarly,  the  ability  to  perform  future  IVHS  services  is  also  documented.  With 
this  information  as  a foundation  we  present  our  conclusions  and  recommendations. 

Table  5 indicates  a situation  in  which  standardization  can  be  helpful.  Notice  that  several 
existing  or  prototype  systems  have  the  capabilities  to  perform  all  the  listed  CVO  user 
services.  These  systems  also  can  support  the  activities  implied  by  the  three  data  models 
defined  earlier.  In  addition,  they  have  the  basic  ability  to  perform  the  functions  expected  to 
be  needed  for  the  listed  IVHS  services.  It  is  our  view  that  a standard  should  not  be  adopted 
that  calls  for  less  capability  than  these  systems  already  provide.  We  say  this  because  these 
systems  provide  capabilities  for  supporting  future  IVHS  services  and  because  the  systems 
with  lesser  capability  are  not  significantly  less  costly. 
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However,  among  the  systems  with  these  capabilities,  the  different  developers  employ 
different  communications  protocols  and  different  RF  technologies,  making  all  incompatible 
with  each  other. 

The  existence  of  several  possible  solutions  and  the  FHWA  interest  in  standardizing  as 
quickly  as  possible,  make  creating  a new  solution  unnecessary  and  undesirable.  It  is  our 
view  that  a suitable  standard  can  be  obtained  that  specifies  methods  used  in  those  systems 
that  are  most  capable.  The  technical  aspects  that  we  believe  are  appropriate  for  CVO  and 
should  be  specified  for  standardization  are  explained  next 

FHWA  has  specified  as  a technical  requirement  that  the  CVO  VRC  standard  shall  provide 
for  multilane  operation.  We  recommend  that  a wide-area  protocol  and  system  configuration 
be  used  to  accomplish  this  rather  than  a lane-based  approach.  There  are  several  reasons  for 
this.  First,  a wide-area  approach  minimizes  that  impact  on  the  roadway  infrastructure 
compared  to  lane-based  techniques.  This  is  important  since  future  installations  will  include 
retrofits  to  existing  weigh-stations.  Further,  a wide-area  approach  permits  operation  of  a 
right-lane  only  type  of  configuration  (such  as  that  planned  for  1-75)  and  sttil  allows  for 
expansion  to  coverage  of  other  lanes  without  addition  of  equipment  for  additional  lanes. 
We  feel  the  advantage  of  lane-determination  in  lane-based  configurations  is  outweighed  by 
the  need  to  handle  cross-lane  reads  and  the  fact  that  techniques  are  being  developed  for  lane 
determination  in  wide-area  systems.  We  also  feel  that  the  fact  that  a vehicle  is  in  the 
communication  zone  longer  in  a wide-area  system  makes  it  possible  to  consider  longer 
messages  and  more  complicated  transactions  in  the  future. 

Of  the  three  systems  that  were  found  to  meet  the  CVO  user  services  requirements,  data 
model,  and  IVHS  needs,  two  support  both  wide-area  and  lane-based  protocols  and  one 
supports  only  a lane-based  protocol.  The  two  wide-area  protocols  are  ftoposed  Standard 
A and  Proposed  Standard  C.  These  were  discussed  in  Section  4.1.2  and  4.1.4 
respectively.  We  recommend  Proposed  Standard  A for  CVO  VRC  for  several  reasons. 
While  both  protocols  have  been  placed  in  the  public  domain  by  their  developers.  Proposed 
Standard  A is  much  farther  along  in  the  process  of  review  and  standardization.  It  has  been 
available  in  the  public  domain  longer,  and  has  been  subject  to  review  by  an  ASTM  working 
group  that  includes  participants  from  multiple  VRC  system  vendors  and  interested  users. 
As  such,  it  has  achieved  a level  of  formal  definition  and  documentation  that  is  not  available 
with  any  other  public  domain  wide-area  protocol.  While  not  yet  complete,  this  "head-start” 
is  in  line  with  the  FHWA  goal  of  attaining  a standard  as  soon  as  possible. 

This  protocol  includes  features  that  will  enhance  its  ability  to  carry  out  CVO  and  other 
functions.  The  protocol  incorporates  a mechanism  for  the  reader  to  access  vehicle  devices 
external  to  the  tag.  This  will  be  needed  for  access  to  smart  card  readers  and  external 
memory  or  computing  systems.  The  protocol  is  also  being  extended  to  permit 
communication  with  HELP  and  CALTRANS  type  tags  during  otherwise  unused  guard  time 
periods. 

Proposed  Standard  A is  designed  for  use  with  2-way  active  RF  technology.  For  this 
reason,  and  because  of  the  smaller  bandwidth  requirement  of  this  wide-area  active 
configuration  (1.5  MHz)  compared  to  the  larger  bandwidth  requirement  of  the  proposed 
wide-area  backscatter  configuration  (6  MHz),  we  recommend  use  of  active  tag  technology 
for  VRC.  In  addition,  we  feel  it  is  an  advantage  that  there  are  multiple  developers  of  active 
tags  that  could  support  Proposed  Standard  A.  It  should  also  be  noted  that  existing  (HELP) 
and  planned  (1-75)  CVO  mainline  bypass  programs  employ  active  technologies  and  that  the 
1-75  program  will  employ  an  early  version  of  Proposed  Standard  A.  This  protocol's 
allowance  for  communication  with  CALTRANS  and  HELP  devices  during  protocol  guard 
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times  will  nonetheless  provide  coordination  of  communication  with  CALTRANS 
backscatter  technology  devices. 

We  also  recommend  consideration  of  the  use  of  variable  length  frames.  This  capability  is 
supported  by  Proposed  Standard  C but  not  by  Proposed  Standard  A.  Given  the  developing 
nature  of  VRC  communications,  it  is  hard  to  predict  the  optimum  frame  length  or  best 
number  of  activation  slots.  The  ability  to  specify  these  dynamically  could  prove  useful. 

Our  examination  of  the  requirements  for  an  on-board  computer  interface  found  that  few 
specific  requirements  have  been  identified  by  users  and  that  developers  have  not  strongly 
proposed  any  particular  interface.  This  has  not  lead  us  to  any  definitive  position  on  the 
related  issues,  but  we  are  able  to  make  a few  observations  and  recommendations.  The 
primary  use  for  the  on-board  computer  interface  at  this  time  is  for  support  of  a smart-card 
device  to  be  used  with  a card  that  contains  driver  specific  information.  This  requires  only  a 
relatively  low  data  rate  interface,  and  can  therefore  easily  be  handled  through  an  RS-232  or 
J-1850  interface.  With  both  of  these  currently  available  on  tags,  we  recommend  using  the 
J-1850  interface  because  of  its  greater  data  rate.  For  future  applications  in  which  the 
modest  data  rate  of  J-1850  (41.6  Kbits  per  second)  is  insufficient,  we  must  look 
elsewhere.  This  is  a very  active  area  in  communications  system  development.  A number 
of  protocols  have  been  developed  or  are  being  developed  for  use  in  distributed  control, 
most  aimed  at  fieldbus  communications  for  manufacturing  systems.  Of  those  protocols 
presented  in  Section  4.2,  the  CAN  bus  has  seen  application  in  vehicle  implementations.  Its 
data  rate  of  up  to  1 Mbyte  per  second  is  in  line  with  the  500  Kbits  per  second  data  rates  of 
current  tag  technology.  We  recommend  further  examination  of  CAN  for  evaluation  of  cost, 
performance  and  implementation  considerations. 

Finally,  we  remind  the  reader  that  few  operational  CVO  mainline  bypass  installations  exist, 
and  none  employ  wide-area  communications.  The  recommendations  presented  here  are  not 
the  result  of  any  performance  history  for  installed  systems,  but  on  an  analysis  of  the  best 
available  information  we  could  obtain  at  the  time  of  this  study.  Multiple  sources  were  used 
in  developing  the  requirements  and  in  determining  the  current  and  expected  near-term 
capabilities  of  various  technologies.  In  many  cases,  the  available  information  from 
developers  is  sketchy  and  not  well  documented,  and  of  course,  always  subject  to  change. 
Nonetheless,  we  feel  our  recommendations  have  been  reached  through  a careful  analysis 
and  weighing  of  what  we  believe  to  be  likely  technical  capabilities  and  necessary  user 
services. 
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7.  Appendix:  Data  Element  Size  Estimates 

The  following  provides  additional  insight  into  how  we  estimated  the  lengths  of  the  various 
data  elements  for  CVO  VRC  applications.  When  alphanumeric  characters  are  represented, 
a 6-bit  ASCn  code  is  used.  A table  for  the  6-bit  ASCII  code  follows. 


• Carrier  Name  120  bits 

(20  characters  * 6 bits/character) 

• Carrier  ID  Number  84  bits 

(14  characters  * 6 bits/character) 

• What  permits,  if  any,  the  vehicle  is  operating  under  16  bits 

(16  bit  bit-mapped  storage  area  for  16  permits) 

(1  - vaHd  permit,  0 - no  permit) 

• Whether  or  not  carrier  is  registered  in  a "base  state"  4 bits 

(0001  - yes,  0000  - no) 

• Base  state  for  vehicle  registration  (IRP)  8 bits 

(using  a state  code  0 - 49) 

• Base  state  for  fuel  tax  reporting  (IFTA,  RFTA)  8 bits 

(a  state  code  0 - 49) 

• License  plate  number  and  state  for  each  vehicle  unit  50  bits 

(7  characters  for  plate  and  8 bits  for  state  code) 

• Whether  or  not  cargo  is  hazardous  materials  4 bits 

(0001  - yes,  0000  - no) 

• Tag  ID  32  bits 

(32  bit  factory  installed  number  that  is  unique  to  the  tag) 

• Weight  of  the  vehicle  at  last  weighing  12  bits 

(Weight  of  vehicle  in  lOO's  of  kgs) 

• Safety  flags  4 bits 

(4  bit  value  to  signify  recent  safety  violations) 

• Temporary  permits  120  bits 

4 bit  permit  code 

8 bit  state  code 

12  bit  permit  expiration  date 


5 slots  for  temporary  permits 
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The  following  is  driver  related  data  that  could  be  stored  on  a smart  card  device  and 
loaded  onto  the  truck  when  the  driver  comes  on  duty.  Each  driver  would  have  a 
smart  card  that  would  contain  the  information  about  him/her. 


• Driver  Name 

120  bits 

(20  characters  * 6 bits/character) 

• Time  driver  came  on  duty 

28  bits 

(based  on:  6 bits  for  minutes 

(60) 

5 bits  for  hour 

(24) 

4 bits  for  month 

(12) 

6 bits  for  day 

(31) 

7 bits  for  year 

(99) 

• Driver  ID  Number  (CDL  number  & state  of  license)  86  bits 

(13  characters,  i.e.  S3 16465040976) 

(and  8 bits  for  the  state  code) 


• Driver  Social  Security  Number  (to  access  NLETS)  32  bits 

(9  digit  numeric  value) 


TOTAL: 


560  bits 
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Six-Bit 

Ascn 

Character 

Decimal 

Value 

Six-Bit 

ASCn 

Character 

Decimal 

Value 

Six-Bit 

ASCn 

Character 

Decimal 

Value 

(space) 

0 

6 

22 

L 

44 

1 

1 

7 

23 

M 

45 

2 

8 

24 

N 

46 

# 

3 

9 

25 

0 

47 

$ 

4 

26 

P 

48 

% 

5 

27 

Q 

49 

& 

6 

< 

28 

R 

50 

c 

7 

= 

29 

S 

51 

( 

8 

> 

30 

T 

52 

) 

9 

9 

31 

U 

53 

* 

10 

@ 

32 

V 

54 

-H 

11 

A 

33 

w 

55 

12 

B 

34 

X 

56 

- 

13 

C 

35 

Y 

57 

14 

D 

36 

z 

58 

/ 

15 

E 

37 

[ 

59 

0 

16 

F 

38 

\ 

60 

1 

17 

G 

39 

] 

61 

2 

18 

H 

40 

A 

62 

3 

19 

I 

41 

_(underline) 

63 

4 

20 

J 

42 

5 

21 

K 

43 
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